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THEME 


Modern  tactical  warfare  is  characterized  by  decentralized  activities  of  highly  mobile, 
dispersed  forces  operating  in  an  environment  replete  with  technologically  complex  and 
sophisticated  equipment.  These  equipments  are  used  to  acquire,  transmit  and  process 
massive  amounts  of  data  so  as  to  glean  the  intelligence  required  for  the  prosecution  of  field 
actions.  Indeed  the  successful  conduct  of  a tactical  operation,  the  ability  to  coordinate  the 
many,  varied  aspects  of  a dynamic  tactical  situation,  depends  critically  on  a combattants 
technical  capability  to  handle  data  efficiently  and  expeditiously. 

The  Avionics  Panel  of  AGARD,  in  recognition  of  the  rapidly  advancing  state-of-the-art 
in  data  handling  and  the  need  for  the  dissemination  of  information  on  this  subject  to  the 
NATO  countries,  devoted  its  1 5th  Technical  Meeting  in  Amsterdam,  Netherlands  on  4-7 
November  1968  to  a Symposium  on  “Techniques  for  Data  Handling  in  Tactical  Systems”. 

In  the  ten  years  since  that  meeting,  techniques  applicable  to  the  solution  of  the  multi- 
faceted problems  of  tactical  data  handling  have  been  emerging  at  an  ever  increasing  rate. 
There  have  been  significant  advances  in  solid  state  computing  devices  and  memories,  displays, 
structured  programming,  higher  order  languages,  operating  systems,  wideband  communica- 
tion networks,  microprocessors  etc.  This  is  fortunately  in  consonance  with  and  probably 
stimulated  by  the  explosive  growth  in  information  requirements.  Equipments  based  upon 
and  incorporating  these  techniques  have  been  developed  and  introduced  into  the  inventory 
to  enhance  the  military  technical  capability  in  this  area. 

The  purpose  of  this  conference  is  to  review  and  present  the  latest  developments  in 
techniques  in  data  handling  which  are  applicable  to  the  NATO  tactical  environment. 


IRVING  J.GABELMAN 
Program  Chairman 
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EXPLOITING  TECHNOLOGY  FOB  OPERATIONAL  DECISIONS 


I.H.  Mirman 
SHAPE  Teohnioal  Centre 
The  Hague 
Betherlande 


SDMMAHT 


The  ohallenge  ie  to  harness  the  new  teohnology  by  ooneeioue  exploitation  and  foous  on  draaatloally 
improving  taotloal  syateme.  The  past  deoade  haa  seen  an  explosive  growth  of  technology)  data  ie 
available  by  the  pound,  but  the  aan-in-the-loop  is  unable  to  take  advantage  of  the  voluae  and 
apeotrua  of  the  data.  Teohnology  growth  has  not  bsen  aatohsd  by  a growth  In  solenoe  of  ooaaand 
and  oontrol.  It  is  tine  to  shift  attention  froa  teohnology  whioh  is  spswing  out  voluaes  of  data, 
and  look  at  the  deoision  maker's  problea.  His  needs  need  to  be  the  beginning)  teohnology  needs 
to  be  a means  to  that  end,  not  an  end  in  itself.  Sharp  foous  is  nseded  on  the  transition  of 
ooaaand  and  oontrol  froa  a folk-lore  - undefined  art  - to  one  that  is  based  on  eoienoe.  Major 
attention  ie  needed  in  providing  snapshot  situation  assessaent)  deoision  options  ooupled  with 
oonsequenoes ) olossd-loop  deoision  oriented  information  systeas  with  poeitlve  feed-baok  and  a 
dedicated  drive  to  oonoelve  and  develop  soienoe  of  ooaaand  and  oontrol.  One  needs  to  think 
systeas  not  techniques,  deoisions  not  data. 


IHTBOMTCTIOH 


This  paper  ie  addressed  to  the  needs  of  the  taotloal  deoision  aaker,  and  to  that  end,  rather  them 
disouee  teohnology  per  ee,  the  needs  of  the  C2  decieion  aaker  are  addressed.  The  notion  that  C2 
is  a olosed-looped,  servo-like  systea  with  appropriate  feed-baok  is  introduoed.  Past  problems 
have,  to  a large  degree,  been  driven  by  acquisition  of  hardware  prior  to  evolving  a C2  prooesa 
needed  to  aohieve  adequate  opportunity  to  perfora  both  the  ooaaand  and  the  oontrol  function. 
Additionally,  the  notion  that  C2  is  hsavily  communication*  oriented  have  resulted  in  a huge  input 
of  data,  not  necessarily  information.  Little  attention  haa  been  given  to  the  orderly  prooess 
needed)  defining  of  information  needed  to  aohieve  a given  deoision.  While  inforaation  theory 
dates  baok  to  40' s,  management  of  inforaation,  particularly  text,  haa  not  developed  to  improve 
either  ooaaand  or  oontrol.  The  dynaaio  threat  deaande  fast  deoisions,  and  a new  means  must  be 
provided  to  selectively  develop  information  froa  the  high  voluae  of  data,  and  provide  the  deoieion 
maker  with  options  and  assooiated  oonsequsnoes.  A number  of  suggeetions  are  made  that  merit 
additional  work. 

1.  With  this  symposium  dedicated  to  teohnology  for  data  handling,  one  should  recognize 
the  explosive  growth  of  teohnology,  mloro-oirouits,  aioro-ooaputers  and  signal  processing,  and  the 
nsw  doors  it  has  opened  in  terms  of  dsteotion,  oontrol  and  weaponry.  We  are  at  the  beginning  of  a 
new  era  - abundant  teohnology.  The  dramatic  explosion  in  teohnology  will  have  a marked  and  even 
unpredictable  impact  on  the  future.  In  retrospect  though,  it  is  mind-boggling  to  realize  that  a 
room-sized  oomputer  of  a deoade  ago  is  now  sized  to  hold  in  your  hand.  I am  sure  that  the  fine 
papers  in  the  next  few  days  by  teohnology  experts  will  oover  these  exoiting  advances. 

2.  I will  Instead  disouss  teohnology  as  a means  to  an  end.  An  end,  whioh  is  expressed  in 
terms  of  the  military  need  for  oommand  and  oontrol  systems  whioh  are  responsive,  olosed-looped  and 
adaptive. 

3.  The  explosive  teohnology  growth  unfortunately  has  not  been  matched  by  a comparable 
growth  in  its  use,  nor  in  the  soienoe  of  oommand  and  oontrol  as  it  applies  to  military  needs. 

4.  In  the  past  deoads  or  more,  beoause  of  the  opportunities  offersd  by  new  teohnology, 
there  has  been  a tendenoy  for  us  to  introduce  new  boxes  whioh,  by  themselvss,  offered  tremendous 
improvement  to  a function  over  the  past.  Yet  there  has  been  a lack  of  ooheslon  in  the  use  of 
these  boxes  in  satisfying  an  overall  system  need.  As  a result,  we  tend  to  build  oommand  and 
oontrol  systems  froa  the  bottom  up  by  seleoting  the  boxes  and  trying  to  find  use  for  these  in  an 
operational  system.  This  has  been  enoouraged  to  a large  degree  not  only  by  the  exoiting 
opportunities  that  teohnology  offered,  but  the  faot  that  these  boxes  wsre  tangible  dsfinitive 
end-produets.  Whereas  effeotive  use  of  these  boxes  resulted  in  systems  often  hard  to  define  or 
visualize  as  a preoursor  to  the  aoquisition  of  these  boxes  - this  results  in  the  "box  syndrome". 

3.  It  reminds  one,  to  use  an  analogy,  of  a composer  of  ausio  suoh  as  the  deaf  Beethoven, 

who  wrote  symphonies  and  carefully  evolved  a net  of  data  and  notes  on  how  the  various  instruments 
he  visualized  best  contributed  to  the  musio  (or  soore)  he  had  oompoeed.  The  oonduotore  who  play 
this  ausio  seleot  the  instruments  as  the  oompoeer  presorlbed,  but  the  skill  of  the  oonduotor  is 
keyed  to  his  suooess  in  achieving  the  Intent  of  the  composer's  soore  (HUMAN,  X.H.,  1974)* 

6 . In  oontrant,  in  oommand  and  oontrol  systems,  in  the  past  we  tended  to  seleot  the 

"instruments"  first,  and  then  tried  to  compose  the  "soore"  afterwards.  The  operator  is  often 
given  a set  of  equipment  and  is  on  his  own  to  evolve  the  best  way  to  utilise  it  (MIHMAH,  I.H.  1974)« 
Today  we  do  it  iteratively  with  the  operator  as  a partner,  nevertheless  evolving  the  prooees 
la  difficult. 


I 


7.  From  the  military  point  of  view,  oommand  and  oontrol  systems  are  the  wherewithal  in 

support  of  military  notion.  War,  in  the  final  analysis,  oonoems  itself  with  two  segments  of 
aotivltyi  communication  of  information  and  the  delivery  of  energy. 


8.  This  paper  will  foous  on  only  one  of  these  two  segments!  oommunioation  of  information 

(COI),  with  the  ohjeotive  of  the  use  of  that  information  to  the  effective  delivery  and  use  of  that 

energy.  Implicitly  then,  one  needs  to  examine  information  needs  of  a decision  maker  who  must 
deoide  if,  how,  when  and  where  to  utilize  his  forces. 

9*  The  growth  of  communication  technology  has  been  suoh  that  data  rates  have  Increased 

well  beyond  man's  ability  to  absorb  them,  and  while  there  la  no  doubt  that  new  technologies  on  the 

horizon  will  increase  these  data  rates  by  orders  of  magnitude,  we  have  yet  to  foous  on  the  human's 
ability  to  take  full  advantage  of  this  form  of  data. 

10.  Unlike  that  nation  in  tb«  Middle  East  that  selects  its  military  personnel  as  a function 

of  the  size  of  shoes  they  have  available  in  stock,  we  need  to  find  a way  of  tailoring  our 
technological  produots  to  satisfy  the  man  rather  than  vice  versa. 

Ideally,  a closed-loop  oommand  signal  system,  which  oonsists  of  a series  of  L networks) 
one  for  data;  information  deoislon  and  exeoution,  with  feed-back  oontrol  to  aohieve  a stable, 
critically  ooupled  servo-like  system,  is  needed.  However,  the  input  to  the  system  is  far  from 
ideal;  it  is  conditioned  by  noise,  since  it  is  usually  data  and  Information  whloh  range  from  fact 
to  rumour,  poor  intelligence,  biased  information,  eto.  The  noise  in  the  loop  which  represents 
information  of  unknown  quality,  oould  be  reduoed  by  subjeotlve  judgement  of  the  deoislon  maker. 

Key  in  this  loop,  of  oourse,  is  the  decision  maker  himself,  and  a way  needs  to  be  found  of 
extracting  the  information  content  of  a massive  set  of  data  and  presenting  it  in  palatable  form. 

The  subjective  judgement  he  exeroises  is  a function  of  experience,  training,  and  what  is  a 
difficult  to  define  factor  that  is  best  called  "intuitive  response". 

12.  The  feed— baok  faotors  that  oontrol  the  stability  of  the  servo— like  oommand  and  control 
system  are  not  easily  quantified,  but  oan  best  be  Identified  by  at  least  three  possible  factors  if 
one  considers  the  olosed-loop  system  to  consist  of  3 1 networks  in  series; being  the  feed-back 
after  data  has  been  converted  to  information;  £ 2 being  the  feed-back  that  couplas  the  decision 
maker  to  the  information  souroe  and  is  effectively  driven  by  "intuitive  response";,^? 3 being  the 
feed-back  on  result  of  exeoution  of  a decision  and,  in  effect,  the  major  contributor  to  the 
"oontrol"  function  of  the  system.  In  the  real  world,  however,  ^3  1 is  over-coupled  with  excess 
information;^  2 and,/S  3 are  usually  under-coupled,  and  as  a result  system  stability  is 
difficult  to  aohieve. 

13.  The  intuitive  response  part  otfl  2 is  obviously  personality  sensitive,  hence  the 
system  must  be  oapable  of  coupling  effectively  to  a particular  decision  maker  (DM),  and  have 
flexibility  to  perform,  when  other  decision  makers  take  over.  Unfortunately,  in  the  past  our 
systems  were  often  designed  to  meet  the  original  deoislon  maker's  requirements  and  were  generally 
delivered  Borne  seven  or  more  years  later  when  a new  deoislon  maker  is  the  recipient  of  the  system. 
Recognizing  every  individual  has  a finite  Information  oapaoity,  and  unique  intuitive  response, 
systems  in  the  past  may  not  have  been  flexible  enough  to  accommodate  the  ohange. 

14.  In  any  given  country,  commanders  rise  to  their  position  as  a result  of  a spectrum  of 

experience,  oulture,  language,  training,  tactics;  all  are  conditioned  by  their  national  polioies, 
doctrines  and  inter— service  relationships,  and  all  have  developed  their  own  management  strategies 
and  Intuitive  responses.  Immerse  this  conditioned  commander  and  his  staff  in  a NATO  environment 
and  he  is  faced  with  a series  of  unanticipated  problems,  particularly  in  command  and  control. 
Communications  under  suoh  conditions  are  seriously  affeoted,  as  well  as  his  information  require- 
ments. In  some  instances,  basic  procedures  of  command  may  differ.  For  example,  one  national  view 
might  be  to  command  the  taking  of  Target  'X'  by  simply  saying  it,  whereas  another,  for  the  same 
objective,  could  prepare  a multi-page,  detailed  message  on  taking  Target  'X',  along  with 
instruction  « of  constraints  and  rendezvous,  and  logistio  support,  reporting  sequences  and 
procedures,  leaving  little  initiative  to  the  commander.  This,  of  oourse.  Imposes  severe  stress 

on  C2  systems,  that  challenges  system  designers.  Though  problems  of  this  nature  are  solved,  they 

have  been  brute-foroe  solutions  that  need  refinement,  particularly  in  stress  situations  that  are 
time-sensitive. 

15.  Efforts  to  anticipate  this  problem  have  been  in  the  form  of  providing  exoess  data. 

Indeed,  new  teohnology  available  enoouraged  this  flood  by  virtue  of  high  speed  oircults  with 
printers  now  exoeeding  3000  lines/minute,  but  since  humans  oan  only  read  in  the  order  of  30  lines/ 
minute,  one  minutes  worth  of  messages  take  one  man  100  minutes  to  read  - of  oourse,  if  time  is 

cri tical , one  needs  more  people.  And  with  this,  a chain  of  reactions  oocurs.  Sinoe  this  volume  of 

people  (M)  need  to  ooordinate  and  interaot  the  law  takes  over,  resulting  in  interactions 

whioh  are  effectively  a funotion  of  M2/2  (WIEKHORST,  F.,  1977).  These  interactions  oould  delay 
rather  than  speed  up  the  information  flow.  This  then,  diotates  a need  to  consider  limiting 
manpower,  and  seeking  technical  solutions  to  the  flood  of  information  and  its  management  as  well 
as  ensuring  we  satisfy  the  need  for  "intuitive"  information. 

16.  Everyone  has  his  own  notion  as  to  what  a C2  system  is,  or  is  not.  Like  the  study  by 
British  Transport  Authority  on  bus  schedules  whloh  resulted  in  a finding  that  stated  schedules  oould 
be  met  - if  they  did  not  stop  to  pick  up  passengers  (RYAN,  P. , 1977).  We  may  have  forgotten  the 
prime  purpose  of  the  system.  In  the  oese  of  C2,  it  is  to  satisfy  a single  oommander  at  a given 
eohelon.  C2  is  intangible  because  it  is  "a  process"  that  knits  men,  equipment  and  oommander 
together. 


17.  To  thla  end  than,  It  might  be  beat  for  aa  to  examine  the  naeda  of  this  commander  in 

terms  of  ita  impact  on  oommunioation  of  information. 
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18.  In  diaouaaiona  with  oommandera  you  find  that  they  do  not  think  in  terms  of  any 
elaborate  oonoepta,  but  rather  strea  the  eaaential  needs  of  new  and  changed  information  and 
having  ability  to  dieousa  options  and  opinions. 

19.  Charaoteriatioally,  eaoh  commander  has  hia  own  personal  view  obviously  conditioned  by 
his  culture,  training  and  intuition,  and  surely  as  a commander,  he  must  be  a realist. 

20.  Chess  has  been  olted  as  a game,  but  in  faot  von  Neumann  viewed  it  as  "a  well-defined 
form  of  oomputation".  Now  real  games  are  not  like  that  at  all.  Beal  life  oonslsts  of  bluffing, 
tactics  of  deception,  and  asking  what  the  other  man  is  going  to  think  I mean  to  do.  Beal  games 
do  not  have  preoise  solutions  that  chess  has  (BB0N0VSKI,  J.,  1973).  In  this  sense  then,  the 
decision  maker  needs  information  to  permit  him  to  determine  what  his  opponent  perceives  - to 
permit  him  to  exercise  his  intuitive  Judgement,  based  on  what  odds  he  thinks  exist,  in  his  gamble. 

21.  Of  oourse,  the  deoision  maker's  deoision  is  a command,  but  a responsive  system  is 
needed  to  provide  a capability  to  implement  and  control  that  decision.  In  essence  then,  one  must 
put  in  perspective  a total  Or  system  rather  than  discrete  information  per  se  in  a given  environment. 
Given  information  on  enemy  intentions  and  peroeptions,  the  decision  maker  must  be  oapable  of 
defining  targets,  developing  strategy  and  effectively  employ  his  force. 

22.  Bence,  we  must  find  ways  of  providing  him  with  options  along  with  oonsequenoes,  to  aid 
in  the  decision  process.  The  notion  of  developing  response  algorithms  that  provide  sets  of 
weighted  options  and  their  respective  oonsequenoes  appears  possible  and  needs  attention. 

2 

23.  From  the  commander's  point  of  view,  C must  aid  him  in  controlling  his  force, 
avoiding  errors  and  achieving  his  objectives.  From  the  technical  point  of  view  we  need  to  relate 
these  to  his  information  needs. 

24.  Implioit  in  the  oommander’s  needs  is  being  able  to  operate  and  survive  in  hostile 
environments;  his  information  needs  are  many;  (WELCH,  J.A.,  1978) 

(a)  Information  that  would  dictate  deployment  on  short  notice. 

(b)  Ability  to  operate  and  survive  in  a variety  of  conflicts. 

(c)  Anticipate  what  his  enemy  perceives  and  gambles  based  on  information  of 
enemy  intentions,  and  ourrent  and  projected  information  of  enemy 
looation. 

(d)  Anticipate  surprise. 

(e)  Avoid  suspense. 

(f)  Needs  to  have  high  oonfidence  in  enemy  identification. 

(g)  Needs  sufficient  information  to  target  his  weapons  against  selected 
targets  and  rapid  assessment  of  Information  on  results. 

(h)  Needs  information  on  real-time  basis,  with  oonfidenoe  on  posture 
and  ourrenoy  of  his  own  forces. 

(l)  Needs  Information  that  keeps  him  constantly  aware  of  actions  he  has 
directed  and  their  results  - this  feed-baok  is  an  essential  and  a 
system-oonfidence-faotor  that  he  is  very  dependent  on. 

(J)  Finally,  he  needs  information  and  identification  capability  to 
avoid  using  his  weaponry  against  friendly  foroes  by  mistake. 

25.  To  add  to  his  problems  a senior  NATO  commander  is  beset  with  political  constraints 
whloh  impose  a heavy  information  demand  on  system  and  particularly  effeots  communications. 

These  oan  influence  his  decisions  at  various  stages  of  oonfliot,  for  example  in  foroe  deployment, 
reinforoement,  and  weapon  use. 

26.  Immersion  of  this  commander  and  his  staff  in  a NATO  environment  adds  additional 
dimensions.  One  is  language  - while  one  oan  talk  in  other  languages,  and  in  NATO  there  are 
eleven  (11),  the  problem  of  oomprehending  the  intent,  particularly  in  oombat  stress  environment, 
in  someone-else's  language  is  difficult  (HAIG,  A.M.,  1978).  In  stress  "situations  one  tends  to 
resort  to  one's  own  language,  where  you  oan  say  what  you  mean,  which  can  range  in  style  from 
eduoated  to  gutter  style.  Benoe,  in  oombat  situations  where  multi-nati'enal  oommunioation  is 
essential,  difficulties  oould  arise.  In  situations  where  confidence  of  decisions  is  frequently 
influenced  by  one’s  verbal  statements  as  to  Intent  and  infleotion,  language  and  comprehension 
becomes  an  Important  faotor.  Henoe,  the  likelihood  of  situations  without  conversation, 
particularly  at  high  commander  level,  is  unlikely  in  future.  However,  in  lower  level  oombat 
situations,  technical  means  of  overcoming  the  language  barrier  needs  major  attention.  Of  oourse, 
digital  message  entry  devioes  using  a priori  formed  messages  is  one  possible  solution. 

27.  Another  dimension  is  coordination  between  air/ground  - this  is  not  unique  to  NATO, 
but  what  does  add  an  element  of  uncertainty  is  that  organizations  and  rslatlonships  between 
air/ground  foroes  differ,  though  procedures  and  extensive  training  have  resolved  these  differences. 
However,  this  area  obviously  has  a significant  lmpaot  on  data,  and  information,  and  the  amount  of 
communication  needed. 


» 
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28.  The  equipment  sub-systems  in  C involve,  of  course,  sensors,  communications,  data 
processing  systems  and  their  associated  logistic  support.  In  the  context  of  the  last  decade,  the 
oommander  in  a tactical  force  is  now  faced  with  an  additional  dimension,  namely  that  of 
survivability  in  an  environment  now  threatened  by  new  technology  and  weapons  systems.  This 
dictates  the  vulnerability  of  fixed  tactical  installations.  As  a result,  continuous  movement 
becomes  essential  and,  moreover,  the  vehicles  per  se  must  not  only  be  ooncealable,  but  have  low 
energy  radiation  to  avoid  detection  by  new  technology  sensors,  formalizing  heat  distribution 
from  a deteotor  polnt-of-view  diotates  examination  of  vehicle  size  and  its  components  Including 
people.  The  battlefield  may  well  become  untenable  for  all  but  the  most  agile  and  best  concealed. 

29.  The  great  need  for  mobility  in  view  of  technology  threats  suggests  common-sized 
vehicles,  and  netting  information  on  its  own  dispersed  forces  oreates  major  communications 
problems  in  the  oontext  of  supporting  the  C2  process  for  the  decision  making  functions. 

Maintaining  cohesion  of  forces,  particularly  during  enemy  attack,  demands  a need  for  self- 
sufficiency  of  segments  of  his  mobile  foroe  so  that  graceful  degradation  is  possible.  While 
mobility  fragments  the  operation  physically,  we  are  challenged  to  knit  it  together 
electronically  and  keep  the  oommander  in  control  of  his  foroe. 

30.  New  technological  weapon  systems  and  sensors  have  now  made  it  possible  to  conduct 
combat  at  night,  and  in  Europe  the  poor  weather  conditions  provide  convenient  cover.  If  one  is 
considering  surprise,  the  likelihood  of  attacks  in  this  time  period  is  high.  This  drives  the  need 
then  for  systems  which  provide  for  operations  under  these  conditions  and  cohesion  of  the  force 
becomes  a critical  element.  Under  these  conditions,  the  commander  needs  real-time  information 

of  his  own  as  well  as  enemy  forces;  and  to  avoid  suspense  and  surprise  needs  information  that 
literally  permits  him  to  "see  at  night";  this  night  problem  drives  the  need  for  critical 
information  C2  systems. 

31.  The  dynamic  changes  of  technology  are  not  a challenge  to  the  operational  commander 
since  his  weapon  systems  reflect  production  state  of  art,  and  are  what  they  are.  Accordingly, 
it  becomes  imperative  that  the  system  designers  provide  increased  flexibility  so  that  the 
commander's  options  can  be  supported  in  an  environment  where  the  threat  and  advantages  of 
changing  technology  are  on  the  enemy's  side. 

32.  Message  transmission  is  getting  a "package  of  data"  to  the  right  place  at  the  right 
time;  the  contents  of  package,  on  receipt,  need  to  be  assessed  as  to  "value"  and  intent  and  a 
decision  made  as  to  its  information  content.  The  latter  is  an  undefined  area  that  "begs"  for 
new  ways  of  deriving  information  for  the  decision  process.  The  tendency  to  increase  bandwidth 
and  channel  capacity  encouraged  by  the  high  data  rate,  needs  to  be  examined  more  carefully 
since  it  provides  license  for  longer  messages  which  increase  the  potential  for  blunders.  Use  of 
written  type  messages  to  convey  information  have  limitations  even  when  the  recipient  is  in  a 
clean,  comfortable  noise-free  environment,  but  immerse  this  message  in  a condition  of  crisis, 
coupled  with  a drastic  change  in  environment,  such  as  arena  of  combat,  and  the  reader  could  turn 
primative , In  many  cases  messages  will  be  misunderstood,  long  messages  not  read,  and  at  worst 
not  even  reach  the  commander. 

33«  It  is  clear  then,  that  information  per  se,  is  fundamentally  an  essential  element  of 

the  commander's  needs.  However,  what  needs  to  be  recognized  is  that  the  commander  does  not 
require  data  per  se,  though  equipment  sub-systems  like  data  processors  for  radars,  weapons  etc., 
do.  He  gets  data  by  the  ton  at  this  point  because  of  our  ability  to  have  high  data  rate 
messages.  What  he  badly  needs  is  information  that  is  fresh,  that  shows  a change,  that  tells  him 
something  he  did  not  know  before,  or  confirms  previous  known  information.  He  also  needs  a 
continuum  of  information  on  the  results  of  actions  he  has  directed  previously,  i.e.  the  t term 
I mentioned  above.  He  cannot  be  under  suspense  or  be  surprised.  Director  Alfred  Hitchcock  once 
said  "suspense  is  a matter  of  knowledge.  If  a bomb  unexpectedly  goes  off  in  a movie  - thats  a 
surprise.  But  if  the  audience  knows  a bomb  will  go  off  in  5 minutes,  and  the  hero  on-screen 
does  not,  thats  suspense". 

34*  Wiener  and  Shannon  postulated  that  a message,  as  well  as  interfering  noise,  could 

properly  be  described  only  in  'probabalistic'  terms.  This  formed  the  basis  of  information 
theory  back  in  the  40' s.  Criteria  of  acceptability  of  the  message  on  the  part  of  the  users  is 
not  an  'isolated  event'  but  a coupled  one  between  the  source  and  the  user.  The  coupling,  in 
effect,  transforms  data  to  information.  Shannon  essentially  showed  that  change  in  probability 
of  a message  or  event  is  an  indication  of  information.  Information  then,  by  definition,  is  well 
defined,  is  relevant  and  timely,  and  is  in  terms  of  probability. 

35-  While  Shannon's  theorum  has  been  well  exploited  in  the  coding  and  communications 

systems  that  achieve  error  free  streams  of  words,  we  have  yet  to  fully  exploit  his  well-defined 
theory  on  'information',  to  provide  selected  text  messages/statements  of  information  in  terms  of 
their  intent  or  meaning  to  meet  the  commander's  objective,  and  avoid  surprises. 

36.  In  this  past  decade,  the  speed  of  weapon  systems  has  increased  and  the  responses  and 
reaction  time  has  become  time  critical.  In  turn,  need  exists  for  having  higher  speed  processing 
of  data  and  information  to  decision  maker.  However,  the  resulting  flood  of  data  dictates  the 
need  for  the  insertion  of  aotive  filter  processes  that  will  convert  the  data  to  information 
classified  by  message  oontent/lntent  that  has  high  probability  of  interest.  This  is  now  a major 
manpower  "chore". 

37.  We  have  attempted  to  solve  this  problem  by  increasing  manpower.  However,  since  the 
M*/2  law  takes  over,  the  large  masses  of  manpower  could  be  counter-productive  since  they  could 
begin  to  communicate  with  themselves  and  lose  sight  of  the  filtering  objective.  Evidence  of  this 
is  seen  in  software  development  efforts. 
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38.  Nature  has  resolved  this  problem  by  design  of  a nerve  system  that  eliminates 
extraneous  data  and  only  allows  Information  to  pass.  This  technology  Is  perfected,  hut  we  do  not 
know  how  It  works  - and  we  all  have  this  faoillty.  The  synapse  terminal  at  each  nerve  ending  Is 
this  Ideal  filter  - It  rejects  all  signals,  except  those  whose  information  is  intended  for  that 
action  (WIEKHORST,  F. , 1977).  Our  challenge  is  to  duplicate  this  capability  in  C2  system. 

39.  The  availability  of  ASP  has  made  it  possible  to  store  heavy  volumes  of  data.  Of 
course,  data  can  be  stored  forever,  but  slnoe  information  is  time  sensitive,  one  can  have  lots 
of  data  without  information.  Obsolete  or  untimely  data  beoomes  a log  Jam,  and  if  it  continues 
to  be  ignored,  challenges  credibility  of  current  data.  A means  must  be  created  of  disposing  of 
useless  information  and  this  requires  major  attention.  Moreover,  information  that  is  not  tagged 
in  some  way  to  show  its  currency  or  age  may  be  useless  to  a decision  maker  who,  having  doubts 
about  its  currency,  tends  to  lose  oonfidenoe  on  use  of  suoh  systems. 

40.  Key  to  a commander's  needs  is  having  relevant  information  in  a timely  manner,  and 
support  his  intuitive  responses  in  less  time  than  an  opponent  can  react.  More  information  is  not 
always  better  than  less,  no  matter  how  little  we  have,  and  how  bad  things  are,  there  is  always  a 
best  thing  to  do  (WELCH,  J.A.,  1978). 

41.  Use  of  information  derived,  needs  to  be  conveyed  in  snapshot  format)  there  is  a 
notion  that  large-soale  displays  are  key  elements  of  C2  - this  notion  could  be  so  - if  such 
displays  could  oontain  information)  for  example,  a snapshot  of  his  own  force,  the  enemy,  the 
environment,  the  delta  change  over  time,  eto.  However,  while  the  technology  of  creating  and 
projecting  large  soale  displays  has  advanced  dramatically,  the  soienoe  of  the  best  ways  to  convert 
data  to  information,  with  its  associated  probability  in  a given  environmental  situation  and 
display  it,  has  not.  We  need  to  devise  new  methods  of  getting  the  best  out  of  ourselves.  Written 
text  derived  from  the  lesser  oapaoities  of  the  human  ear  which  required  slow  sequential  method  in 
which  one  word  followed  another.  But  a map,  was  an  example  of  how  a great  deal  of  information 
could  be  passed  to  the  brain  in  much  shorter  time  by  use  of  the  eye.  The  development  of 
technology  makes  possible  generation  of  diagrams  in  a way  comparable  to  use  of  maps.  A major 
question  is  how  much  information  is  needed  to  make  the  presentation  of  a scene  as  effective  as  if 
the  perceiver  were  actually  there  (BONDI,  Sir  Hermann,  1978). 

42.  It  is  an  old  adage  that  a picture  is  worth  1000  words  - yet  we  have  still  to  develop 
a satisfactory  means  to  convey  to  the  commander  a meaningful  picture  of  a situation.  Brute  force 
of  video  transmission  to  ground  on  one  hand  is  easy  to  do,  but  its  value  is  far  from  solving  the 
basic  problem.  It  is  another  instance  of  raw  data  that  needs  filtering  to  determine  information 
content.  Use  of  colour  has  not  been  effectively  utilized  to  denote  items  of  command  interest 
proportional  to  its  importanoe.  Real-time  display  of  information,  needs  no  new  display  technology, 
but  we  need  recognition  of  a need  for  coupling  between  the  information  display  and  the  commander's 
eyes  to  take  full  advantage  of  that  little  used  sensor  to  the  brain  of  the  commander.  This  area 
could  be  extremely  fruitful  and  represents  a major  technical  challenge. 

CONCLUSION 

2 

In  conclusion,  it  is  time  that  we  shift  attention  to  the  decision  maker's  plight  in  C - his  needs 
need  to  be  the  starting  point.  This  is  not  only  an  opportunity,  but  indeed  a great  challenge. 

We  need  to  consciously  select  and  adapt  our  abundant  technology  by  thinking  "systems  not 
techniques";  thinking  "decisions  not  data".  The  C2  decision  maker's  problem  of  communications 
of  Information  is  key  to  improving  effectiveness  in  operational  performance  of  tactical  systems. 
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A.Clearwaters 

You  have  spoken  mostly  about  the  man/machine  interface  in  terms  of  machine  to  man,  what  about  the  other  direction? 
Author’s  Reply 

Once  the  class  of  information  needs  are  established,  implementing  it  in  the  machine  should  not  be  too  difficult. 

There  is  no  technology  problem,  what  it  does  require  is  innovation  and  adaptive  techniques  to  improve  the  interface 
such  that  the  Beta  term  of  the  feed-back  loop  permits  a stable  closed-loop  decision  system. 
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D.  Bosnian 

In  view  of  the  enormous  amount  of  data  which  a system  can  provide  to  the  operator;  and  knowing  that  the  decision 
capability  of  the  operator  is  constrained  by  his  central  nervous  system  which  processes  about  10  bits  per  second,  do 
you  recommend  the  design  and  use  of  a general  type  of  preprocessor  or  conditioner? 

Author’s  Reply 

Your  point  recognises  the  limitations  of  the  decision  maker  as  a human.  While  I recognise  that  his  nervous  system  is 
limited  to  10  bits  per  second  - I understand  this  is  the  output-execution  rate  - I’m  not  sure  I know  the  data  rate  of 
conversion  of  data  acquired  by  the  eye/ear  to  the  brain.  * am  convinced  that  the  eye  has  a much  better  capability 
than  in  merely  reacting  to  a written  word.  Your  recommendation  of  providing  preprocessors  or  conditioners  would 
permit  the  digestion  of  the  huge  volume  of  data,  conversion  to  information  and  conditioning  of  this  information 
such  that  it  could  be  displayed  not  in  tabular  or  written  form  but  rather  in  picture  or  snapshot  form  that  effectively 
conveys  the  information  to  the  human.  It  is  indeed  a worthwhile  approach  that  I would  encourage. 


D.  Bosnian 

Do  you  recommend  research  into  general  type  of  tools  for  the  systems  designer  so  that  the  user  will  be  able  to  fully 
exploit  the  system’s  capabilities  as  applied  to  his  particular  process  ( a posteriori  activity  allocation  and  design). 

Author’s  Reply 

Since  an  effective  system  is  one  that  satisfies  the  personality-driven  needs  of  a decision  maker,  there  should  be  a 
class  of  generic  sets  of  information  needs  that  are  inputs  to  his  decision  mechanism,  including  his  intuitive  response. 
Research  into  types  of  information  needed  for  military  decisions  would  certainly  be  worthwhile.  Some  studies  in 
UK  in  role-playing  scenarios  have  indicated  that  intuitive  response  plays  a large  role  in  the  decision.  Modelling  of 
the  process  is  difficult  since  experience  over  the  past  20  years  indicates  that  45%  of  crisis  that  occur  are  usually 
surprise  type  category.  Logically,  a posteriori  analysis  would  be  desireable,  and  could  be  effective  - unfortunately 
obtaining  sufficient  data  after  the  fact  has  been  difficult  because  in  the  real  world  recorded  data  on  the  flow  of 
events  usually  does  not  exist.  However  exercises  such  as  those  like  AbL  Archer  and  others  in  NATO  do  indeed 
provide  such  an  opportunity  and  in  these  cases,  data  is  being  acquired  to  a limited  degree. 

I am  firmly  convinced  that  the  best  tool  for  the  designers  is  the  decision-maker  himself.  Proposals  to  satisfy  the 
user  in  the  form  of  a set  of  experiments  in  which  the  user  actively  uses  and  evaluates,  followed  by  interactively 
improved  experiments  until  the  user  is  satisfied  is  a most  effective  approach. 
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SUMMARY 

This  paper  addresses  the  trends  emerging  in  Naval  Aviation  and  their  impact  on  the 
avionics  community.  New  avionics  concepts  are  discussed  with  emphasis  on  the  technical 
and  managerial  challenges  which  must  be  met  to  assure  their  successful  implementation. 

These  challenges  include  the  software  implementation  of  distributed  network  control  and 
fault  tolerance;  NATO  interoperability  and  standards;  and  logistic  support. 

1.  INTRODUCTION 

The  avionics  concepts  presented  in  this  paper  are  to  satisfy  the  ever  growing  needs  for 
greater  quantities  of  on-board  information  to  be  available  within  a shorter  time  frame. 
Concurrently,  the  trend  toward  smaller  dispersed  aircraft  means  that  less  weight,  volume, 
cooling,  and  prime  power  will  be  available  to  support  these  improved  performance  systems. 
Clearly,  a "brute  force"  approach  to  achieve  the  required  performance  levels  will  not 
work.  We  must  use  all  available  resources  at  all  levels  more  efficiently:  interoper- 
ability of  all  NATO  forces,  cooperative  tactics  between  platforms,  multisensor  correlation, 
complex  waveforms,  improved  signal  processing,  and  automated  decision  aids. 

1.1  THREAT  TRENDS 

Over  the  last  decade,  there  has  been  a substantial  strengthening  of  the  Warsaw  Pact 
capability  to  launch  a major  attack  on  Western  Europe.  Such  an  attack  might  occur  after 
a period  of  mobilization  and  deployment,  or  the  forces  already  positioned  in  Eastern 
Europe  could  attack  without  reinforcement,  and  with  little  tactical  warning  in  the 
midst  of  a major  East-West  crisis. 

Naval  Aviation  forces  participating  in  the  defense  of  Western  Europe  must  face  increased 
quantities  and  types  of  enemy  forces,  significantly  improved  air  defense  systems,  and 
sophisticated  electronic  warfare  capabilities.  These  combined  factors  will  make  the 
Navy  power  projection  mission  more  difficult  than  ever  before. 

Similarly,  the  threats  to  the  sea  control  mission  are  significantly  increasing.  There 
are  more  hostile  platform  types  operating  at  far  greater  ranges.  At  the  same  time, 
there  is  an  increased  dependence  on  the  "sea  lines  of  communication"  for  the  supply  of 
energy  and  other  raw  materials. 

1.2  DEFENSE  TRENDS 

In  order  to  counter  these  threat  trends  within  the  financial  constraints  of  a peacetime 
economic  climate,  President  Carter  and  Secretary  Brown  have  made  major  initiatives  toward 
achieving  a greater  integration  of  NATO  doctrine,  tactics,  procedures,  equipment  and  logis- 
tics support.  At  the  Department  of  Defense  level,  this  policy  is  called  "RSI",  which 
stands  for  rationalization,  standardization,  and  interoperability.  For  the  research 
and  development  community,  the  implementation  of  this  policy  will  mean  increased  emphasis 
on  improved  interoperable  command,  control  and  communications  systems  as  the  keystone 
for  enabling  cooperative  tactics  to  be  employed.  There  will  be  an  increase  in  cooperative 
development  programs  to  reduce  unnecessary  duplication  of  defense  research  efforts. 
Considerable  emphasis  is  being  placed  on  the  development  of  effective  equipment  and  data 
format  standards  which  will  facilitate  both  interoperability  and  logistic  support. 

Within  the  Navy,  the  trend  is  toward  dispersing  its  aviation  capability  at  sea  through 
the  development  of  aircraft  capable  of  operating  from  ships  other  than  a conventional 
aircraft  carrier.  Although  this  approach  has  high  operational  payoff  potential  by  increas- 
ing the  area  covered  by  our  forces  and  decreasing  their  vulnerability  to  a concentrated 
attack,  it  will  require  significant  changes  in  the  way  we  build  aircraft. 

1.3  AVIONICS  IMPLICATIONS 

These  trends  will  have  major  implications  for  avionics  developers.  We  will  have  to  find 
ways  of  providing  better  performance  with  less  of  almost  everything:  weight,  volume, 
power,  cooling,  and  dollars. 

Currently,  the  range  of  some  of  our  airborne  weapons  exceeds  the  effective  range  of  the 
radars  which  control  them.  If  we  are  to  strike  within  heavily  defended  airspace,  we  will 
need  improvements  in  detection  range  and  accuracy,  identification  techniques,  and  in 
addition,  low  probability  of  interception  (LPI) . Communications  links  must  have  greater 
capacities,  be  secure,  jam  resistant,  and  have  LPI.  The  tactical  data  handling  systems 
will  be  required  to  process  greater  volumes  of  data  and  perform  a variety  of  new  tasks 
designed  to  make  the  aircrews  job  easier,  such  as  multisensor  correlation,  threat  recog- 
nition, and  other  automated  decision  aids. 

In  addition  to  those  areas  where  direct  performance  increases  are  needed,  major  emphasis 
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will  be  placed  on  improving  the  efficiency  with  which  we  perform  existing  functions. 

Digital  technology  permits  us  to  use  complex  waveforms  to  reduce  power  requirements  and 
perform  multiple  functions.  Digital  controls  will  be  employed  throughout  the  aircraft. 

Not  only  is  the  control  system  itself  lighter,  the  fact  that  it  can  be  operated  under 
computer  supervision  allows  concepts  of  resource  sharing  and  fault  tolerance  to  be 
implemented.  Improved  tactical  data  handling  and  communications  capabilities  can  offer 
the  platform  designer  even  greater  potential  weight  savings  if  the  cockpit  workload  can 
be  diminished  enough  to  reduce  the  number  of  crew  members.  This  could  be  accomplished 
either  through  on-board  automation  or  by  processing  the  information  remotely  using  data 
links. 

Another  major  way  that  force  dispersion  concepts  affect  avionics  is  that  many  of  our 
aircraft  will  no  longer  have  access  to  the  extensive  maintenance  capability  of  an  air- 
craft carrier.  The  entire  avionics  maintenance  and  support  philosophy  will  have  to 
be  changed  to  enable  these  systems  to  be  maintained  without  extensive  ground  support 
equipment.  For  future  avionics  systems,  we  must  develop  the  maintenance  concepts  con- 
currently with  the  hardware.  While  it  has  long  been  an  objective  to  plan  for  the  total 
life  cycle  of  a system  the  new  maintenance  concepts  must  reach  to  virtually  all  levels 
of  the  design  process.  Considerable  emphasis  will  be  placed  on  the  use  of  built  in 
test  equipment  and  computer  diagnostics  to  isolate  faults.  The  development  of  appropriate 
hardware  standards  will  be  required  to  reduce  the  number  and  types  of  spares  to  manage- 
able proportions  so  that  they  can  be  carried  on  smaller  ships. 

2.  ADVANCED  AVIONICS  CONCEPTS 

The  common  characteristic  of  virtually  all  of  our  avionics  technology  programs  is  that 
they  involve  extensive  use  of  digital  technology.  To  achieve  better  integration  of  all 
information  available  on  the  aircraft  and  better  utilization  of  all  hardware  resources, 
subsystems  on  tomorrow's  aircraft  will  be  interconnected  to  a greater  degree  than 
ever  before.  Various  estimates  obtained  from  aircraft  and  avionics  companies  have 
indicated  that  the  next  generation  of  Navy  Airborne  Early  Warning  and  Antisubmarine 
Warfare  aircraft  will  use  nearly  two  hundred  microprocessors  distributed  throughout 
virtually  every  on-board  electronic/electrical  subsystem.  At  this  series  of  briefings 
you  will  hear  detailed  descriptions  of  three  of  our  key  programs  in  tactical  data  handling: 

Joint  Tactical  Information  Distribution  System  (JTIDS) 

Tactical  Information  Exchange  System  (TIES) 

Avionics  Processing  Architectures 

JTIDS  is  a joint  service  program  to  provide  digital  Integrated  Communications  Navigation 
and  Identification  (ICNI)  services  for  a wide  variety  of  tactical  elements. 

TIES  represents  an  advanced  on-board  architecture  for  satisfying  aircraft  communication, 
navigation  and  identification  requirements.  The  major  difference  in  the  TIES  approach 
is  that  the  hardware  employed  is  general  purpose,  programmable  hardware  that  can  be 
reconfigured  to  meet  mission  needs  or  to  reroute  around  failed  components. 

The  exploratory  development  work  in  avionics  information  processing  architectures  will 
form  the  framework  for  integrating  the  various  components  of  tactical  data  handling  into 
an  avionics  system.  In  order  to  take  fullest  advantage  of  the  flexibility  of  digital 
electronics,  the  system  design  should  be  developed  from  the  top  down,  or  from  general 
requirements  to  the  specific  hardware  and  software  implementations.  The  primary  intent 
of  this  effort  is  to  develop  a formally  structured  methodology  for  the  definition  of 
processing  architectures. 

3.  SYSTEM  DESIGN  ISSUES 

Most  of  the  challenges  faced  by  the  developers  of  tomorrow's  avionics  systems  will  be 
at  the  systems  and  managerial  level.  We  have  an  overabundance  of  digital  technology. 

We  need  to  learn  how  to  use  the  available  technology  effectively  and  this  includes  not 
only  building  an  avionics  system  that  performs  well,  but  also  one  that  can  be  supported 
and  will  work  with  other  platforms.  To  accomplish  this  will  require  strategies  which 
can  control  hardware  and  software  proliferation  without  unnecessarily  inhibiting  the 
introduction  of  new  technology. 

The  use  of  programmable  digital  hardware  frees  the  system  designer  from  the  traditional 
fixed  subsystem  organization  of  avionics  "black  boxes”.  How  the  avionics  system  functions 
ate  allocated  among  hardware,  software,  and  firmware  can  be  determined  by  a variety 
of  design  criteria  and  constraints.  A large  portion  of  the  functional  organization  of 
the  avionics  system  will  exist  only  in  software.  Many  of  the  hardware  resources  will 
perform  multiple  functions  under  software  control.  This  will  enable  implementation  of 
advanced  system  concepts  thiuugh  the  use  of  multisensor  information  correlation,  hardware 
resource  sharing,  and  automatic  fault  tolerance  and  recovery  techniques. 

V 

Not  only  will  much  of  the  system  organization  be  defined  in  software;  the  organizatibnal 
structure  can  be  dynamic,  changing  in  response  to  events  such  as  hardware  failures, 
mission  needs,  or  processing  loads.  While  it  seems  to  be  generally  agreed  that  future 
avionics  information  handling  systems  will  be  "distributed",  there  is  not  a consensus  on 
what  it  is  that  will  be  distributed:  hardware,  software,  processing,  data  bases,  control, 
or  some  combination  thereof. 
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Although  these  systems  offer  exciting  potential  for  overcoming  the  limitations  of  conven- 


2-3 


tional  hardware  systems  and  improving  the  utilization  of  available  information,  they  are 
not  without  risk.  To  accomplish  these  objectives  will  require  some  degree  of  central- 
ized control,  regardless  of  whether  the  system  is  defined  as  distributed,  federated,  or 
hierarchical.  Interspersed  throughout  many  publications  concerning  distributed  process- 
ing systems  for  avionics  are  seemingly  innocuous  statements  that  executives  and  operating 
systems  have  not  been  developed  before  for  large  scale  distributed  systems,  and  that 
the  design  of  real  time  executives  remains  more  of  an  art  than  a science. 

As  a result  of  the  tremendous  technological  advances  in  microelectronics,  avionics 
designers  now  have  the  opportunity  to  consider  system  concepts  formerly  feasible  only 
for  land  or  sea  based  systems.  Large  scale  integration  of  electronic  circuits  has  now 
enabled  equivalent  processing  capabilities  to  be  implemented  within  aircraft  weight  and 
volume  constraints.  Many  of  the  advantages  being  promised  for  future  distributed 
avionics  systems  parallel  those  made  for  the  large  scale  multiprocessing  systems  of  the 
mid  1960's.  Among  these  are:  "modular  system  growth",  "fault  tolerance",  and  "sharing 
system-wide  resources". 

Many  of  these  early  systems  failed  to  live  up  to  the  promises  made  for  them  in  cost, 
time,  or  performance.  One  of  the  most  common  causes  of  failure  was  the  specification  of 
a hardware  system  that  had  the  flexibility  and  expandability  to  handle  any  potential 
requirements,  leaving  the  software  design  until  later. 

From  a manager's  viewpoint,  there  are  sound  historic  reasons  for  following  a moderate 
course  toward  the  introduction  of  these  systems.  The  Navy's  approach  to  development  of 
distributed  avionics  utilizes  a structured  "top-down"  design  process  that  considers 
systems  requirements  as  a package  and  develops  the  hardware  and  software  designs  con- 
currently. The  objectives  are  similar  to  those  of  structured  programming  but  with  wider 
applications.  A major  goal  is  simplicity.  The  availability  of  small  inexpensive  pro- 
cessing and  memory  elements  allows  them  to  be  utilized  less  efficiently  in  order  to 
make  the  system  design  less  complex.  We  are  rejecting  some  of  the  more  exotic  hardware 
configurations  requiring  a complex,  and  as  yet  undeveloped  software  system  in  favor 
of  a more  straightforward  approach  in  order  to  avoid  many  of  the  problems  experienced 
with  prior  system  developments.  A few  illustrations  of  lessons  learned  in  the  develop- 
ment of  ground  based  systems  will  illustrate  the  reason  for  this  concern. 

3.1  THROUGHPUT 

The  real  value  of  a tactical  data  handling  system  is  not  measured  in  bits/microsecond; 
it  is  measured  in  number  of  targets  identified,  weapons  controlled,  measures  countered, 
etc.  When  processors  are  interconnected  and  working  on  a common  problem  their  through- 
put will  be  somewhat  less  than  the  product  of  the  number  of  processor  modules  and  the 
throughput  of  each  processor  unless  the  processes  are  independent,  or  nearly  so.  This 
is  a condition  seldom  found  in  command  and  control  applications. 

When  the  concept  of  multiprocessing  was  new,  the  system  block  diagram  would  illustrate 
a number  of  processors  with  additional  processing  elements  shown  by  dotted  lines,  indi- 
cating the  processors  could  be  added  as  needed  to  meet  expanded  processing  requirements. 
Unfortunately,  the  additional  processing  capacity  was  often  dissipated  in  "overhead" 
activities. 

Figure  1 illustrates  the  results  of  a relatively  simple  simulation  of  the  solution  of 
a set  of  simultaneous  linear  equations  for  an  electrical  network  problem  by  a number 
of  processors.  The  figure  shows  clearly  that  as  the  number  of  processors  is  increased, 
the  incremental  processing  gain  from  each  additional  processor  becomes  smaller  and 
smaller.  In  the  case  where  there  are  only  two  equations  to  be  solved,  additional  pro- 
cessors begin  to  get  in  each  others  way  and  actually  degrade  system  performance. 

The  above  example  was  a simulation  of  the  time  required  to  solve  a set  of  static  equations 
by  a number  of  processors,  not  a large  real  time  command  and  control  system.  Figure  2, 
however,  is  the  system  diagram  of  a major  command  and  control  system  developed  in  the  mid 
sixties.  Note  the  similarity  between  this  diagram  and  those  shown  for  planned  integrated 
avionics  systems.  The  major  difference  is  the  physical  size  of  the  modules. 

The  full  scale  development  of  this  system  had  been  underway  for  over  two  years.  The 
hardware  had  been  delivered,  the  software  specifications  written,  and  the  subprogram  and 
data  base  design  completed.  Over  one  hundred  programmers  were  generating  code.  At  this 
point,  sufficient  information  was  available  to  prepare  an  event  simulation  of  the  system. 

New  estimates  for  the  anticipated  system  loads  and  operating  time  were  prepared  that  in- 
dicated that  five  (5)  seconds/second  of  operating  time  would  be  required,  considerably 
more  than  the  original  estimates.  Theoretically,  one  (1)  second/second  of  operating 
time  is  available  from  each  processor.  When  the  event  simulation  of  the  proposed  system 
configuration  using  three  (3)  processors  was  conducted,  the  maximum  available  operating 
time  was  approximately  2.5  seconds/second,  half  of  that  required.  The  remainder  of  the 
three  (3)  seconds/second  was  used  up  internally  due  to  resource  competition  and  "over- 
head" functions.  More  importantly,  additional  simulations  indicated  that  when  more 
processors  were  added  to  the  system  in  an  attempt  to  meet  the  increased  processing  re- 
quirements, the  available  operating  time  actually  decreased.  These  findings  showed  the 
claims  for  a "modular  system  growth”  could  not  be  realized  in  practice. 

More  processors  could  be  added,  but  no  increase  in  the  amount  of  useful  work  performed 
would  result.  The  only  solution  was  to  make  several  major  modifications  to  the  executive 
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program,  data  base,  and  several  of  the  key  subprograms  in  order  to  provide  real  time 
operation  of  the  system.  At  this  point  in  the  full  scale  development,  these  changes  had 
a major  impact  on  cost  and  schedule. 

3.2  FAULT  TOLERANCE 

The  system  illustrated  in  Figure  2 was  also  intended  to  have  automatic  fault  isolation  and 
recovery  to  provide  an  overall  mean  up  time  of  20,000  hours.  This  was  to  be  achieved  by 
providing  one  spare  of  each  module  type.  When  a module  failed,  the  system  would  automati- 
cally isolate  the  failed  module,  reconfigure  the  system  using  the  spare  module  and  alert 
a maintenance  technician.  Hopefully,  the  failed  module  would  be  repaired  and  be  placed 
on  standby  before  another  module  of  the  same  type  failed.  Then  the  mean  time  between 
failure  and  the  mean  time  to  repair  for  each  module  were  plugged  into  standard  reliability 
equations,  it  was  found  that  the  expected  operating  time  before  a failure  occurred  with- 
out a spare  module  available  was  in  excess  of  22,000  hours,  well  within  the  specification. 
However,  some  module  in  the  system  can  be  expected  to  fail  about  every  sixty  (60)  hours. 

If  there  were  no  automatic  fault  isolation  and  recovery,  this  would  be  the  system  up  time. 

These  calculations,  however,  ignored  the  mechanisms  for  error  detection,  fault  isolation, 
and  system  reconfiguration.  Whenever  a fault  is  detected,  all  processing  is  suspended, 
the  contents  of  the  data  and  error  registers  are  logged  out,  and  the  software  begins  to 
isolate  the  error.  When  the  faulty  module  is  isolated,  and  error  history  table  is  con- 
sulted to  determine  whether  the  error  detected  may  be  a transient  error,  or  whether  the 
module  has  experienced  a hard  failure.  The  system  is  then  either  restarted  or  reconfigured 
and  then  restarted,  and  processing  is  resumed.  The  entire  process  was  expected  to  take 
approximately  twenty-five  (25)  milliseconds.  Thus,  the  system  could  be  expected  to  run 
without  a major  interruption  for  more  than  22,000  hours,  pausing  only  every  sixty  (60) 
hours  or  so  for  twenty-five  (25)  milliseconds  to  "heal"  itself. 

This  can  only  happen  if  the  fault  isolation  and  recovery  works  perfectly  each  and  every 
time.  The  curve  shown  in  Figure  3 illustrates  the  dramatic  drop  in  system  up  time  that 
occurs  when  automatic  fault  isolation  and  recovery  is  only  slightly  less  than  100%  effect- 
ive. At  99%,  the  system  mean  up  time  has  dropped  from  more  than  22,000  hours  to  less  than 
5000  hours. 

The  key  point  here  is  that  the  total  system  reliability  hinges  on  the  reliability  of  the 
fault  isolation  and  recovery  mechanism  which  is  unknown.  It  is  virtually  impossible  to 
analytically  assess  the  correctness  of  a software  package;  there  are  too  many  paths  to 
check  out  individually,  even  with  a computer;  and  a common  rule  of  thumb  states  that  only 
about  one  half  of  software  errors  are  discovered  prior  to  operational  deployment. 

Most  of  the  discussions  concerning  fault  tolerance  center  around  the  ability  to  reconfigure 
around  failed  hardware.  This  must  imply  at  least  some  sort  of  central  control.  Since 
software  has  not  been  perfected  and  probably  never  will  be,  we  cannot  afford  to  build 
systems,  especially  those  involving  flight  critical  functions,  under  the  assumption  that 
the  software  will  work  as  anticipated.  We  must  be  sure  to  address  fault  tolerance  of  the 
software  itself,  particularly  in  critical  areas  involving  system  control.  The  software 
must  be  tolerant  of  internal  faults  as  well  as  faults  in  the  error  detection  logic.  While 
some  form  of  central  control  is  required,  provision  must  be  made  to  prevent  a minor  "glitch" 
from  causing  a system  crash. 

4.  ACQUISITION  AND  SUPPORT  ISSUES 

The  performance  of  an  integrated  avionics  system  is  not  the  only  criterion  for  success. 

The  system  must  be  compatible  with  other  systems  to  achieve  interoperability.  It  must  be 
supportable  and  maintainable,  and  there  must  be  an  effective  transfer  of  the  technology 
from  the  research  and  development  community  to  the  acquisition  community.  These  issues 
are  at  least  as  complex  as  the  pure  technical  issues  since  they  involve  not  only  the 
technical  considerations,  but  legal,  political,  and  economic  considerations  as  well. 

4.1  TECHNOLOGY  TRANSFER 

Integrated  digital  avionics  systems  will  pose  new  challenges  for  technology  transfer.  In 
theory,  digital  technology  should  be  easier  to  transfer  from  the  laboratory  environment 
to  a prime  contractor.  Digital  hardware  should  be  more  easily  integrated  (assuming  that 
the  interfaces  and  formats  have  been  standardized)  with  less  "peaking  and  tweaking"  than 
analog  circuits.  Much  of  the  technology  to  be  transferred  is  in  the  form  of  system  con- 
cepts and  software  which  can  be  directly  transferred  if  our  objective  of  software  trans- 
portability is  achieved.  This  presents  far  less  of  a technology  transfer  problem  than 
in  the  area  of  electron  devices,  for  example,  where  issues  of  productability  and  yield 
are  concerned. 

On  the  other  hand,  an  approach  must  be  found  for  infusing  laboratory  developed  systems  and 
software  technology  into  prime  contractors  without  inhibiting  their  creativity  or  trans- 
ferring risk  to  the  government.  To  attempt  to  do  otherwise  would  be  in  direct  conflict 
with  the  directives  of  higher  authority  both  within  the  Department  of  Defense  and  from 
the  President's  Office  of  Management  and  Budget. 

Much  of  the  technology  transfer  will  likely  be  on  a voluntary  basis.  This  has  been  done 
successfully  in  the  past  both  for  hardware  and  software.  Since  the  physical  integration 
of  electronics  equipment  with  the  airframe  is  a far  more  severe  problem  than  with  other 
platform  types,  many  of  the  decisions  on  avionics  are  left  to  the  airframer.  Yet  many  of 
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our  advanced  developments  do  end  up  on  aircraft  because  the  airframers  propose  them. 

The  existence  of  a laboratory  test  bed  where  new  technologies  can  be  demonstrated 
and  validated  goes  a long  way  toward  bridging  the  technology  gap. 

There  are  several  major  advantages  to  performing  much  of  the  avionics  development  in  a 
laboratory  environment.  Perhaps  the  most  important  is  that  of  off-line  risk  reduction. 
More  and  more  of  the  risk  in  avionics  systems  will  be  at  the  systems  level.  If  the 
traditional  "bottom  up"  approach  of  avionics  integration  is  followed,  it  will  mean  that 
the  major  problems  will  occur  near  the  end  of  full  scale  development  where  there  is 
little  slack  time  left  and  the  cost  and  schedule  impacts  are  greatest. 

Although  much  of  the  work  will  end  up  in  a test  bed  at  a government  laboratory,  most 
of  the  actual  development  will  be  performed  by  contractors,  the  same  ones  who  will  be 
involved  in  the  full  scale  development  and  production  of  new  aircraft. 

In  addition  to  providing  a common  forum  for  the  development  and  validation  of  new 
technologies,  these  assets  will  be  needed  to  assure  that  the  standards  which  must  be 
imposed  are  workable  and  effective.  While  there  is  no  intent  to  inhibit  industry  initia- 
tive or  the  introduction  of  new  technology,  it  is  imperative  that  standards  for  inter- 
faces, data  format,  and  protocols  be  rigidly  enforced  to  realize  our  objective  of  inter- 
operability and  reduced  support  requirements.  The  existence  of  an  off-line  test  bed 
facility  allows  standards  to  be  validated  before  they  are  imposed  on  a major  aircraft 
procurement  and  later  found  to  be  unworkable. 

Finally,  an  in-house  facility  is  required  to  evaluate  competing  proposals  effectively. 
Although  the  potential  performance  of  a radar  or  communications  link  can  be  predicted 
analytically,  the  performance  of  a distributed  tactical  data  handling  system  cannot. 

In  order  to  effectively  evaluate  proposals  for  the  kinds  of  digital  integrated  avionics 
systems  under  consideration,  it  will  be  necessary  to  have  a base  line  from  which  to 
assess  their  performance  and  a simulation  capability  to  verify  the  predicted  performance 
levels. 

4.2  STANDARDIZATION 

Standardization  has  long  been  an  objective  of  the  Department  of  Defense.  Its  direct 
economic  benefits  are  obvious.  Uncontrolled  proliferation  of  different  equipment  types 
results  in  wasteful  duplication  of  effort  for  development  and  acquisition  of  the  equip- 
ment and  excessive  logistics  support  costs.  Now,  however,  with  the  President's  NATO 
initiatives,  standardization  and  interoperability  have  become  key  considerations  of 
foreign  policy  as  well. 

One  of  the  major  reasons  for  our  failure  to  achieve  a greater  degree  of  standardization 
within  the  Department  of  Defense  has  been  the  explosive  rate  of  advance  of  technology. 
Standardization  at  the  equipment  level  has  been  difficult  to  enforce  because  of  the  con- 
tinuing introduction  of  new  products  with  significantly  improved  performance.  This 
led  to  the  present  approach  toward  standards  that  are  "technology  independent",  such  as 
interfaces,  protocols,  data  formats,  and  instruction  sets. 

Theoretically,  the  development  of  technology  independent  standards  should  involve  less 
political  and  economic  considerations  than  equipment  standards,  because  they  are  not 
as  closely  related  to  issued  affecting  production  capabilities  and  competetive  advantages. 

Even  these  standards  may  be  difficult  to  enforce,  however,  since  the  military  market 
constitutes  an  insignificant  percentage  of  the  total  microelectronics  market  and  the 
profit  margins  in  the  commercial  market  are  much  larger.  Therefore,  the  military  impact 
on  decisions  regarding  microcircuit  manufacturing  capability  is  minimel.  In  recognition 
to  this  fact,  representatives  of  the  DoD  are  participating  in  many  non-military 
standardization  activities  such  as  the  Purdue  International  Workshop  or  Industrial  Compu- 
ter Systems,  as  well  as  a multitude  DoD  and  NATO  standardization  committees.  Only  if  a 
large  enough  share  of  the  microelectronics  market  can  agree  on  standards  is  the  situation 
likely  to  stabilize. 

Earlier  problems  with  standards  were  primarily  concerned  with  enforcing  them  within 
government  and  resisting  the  ever  present  temptation  to  waive  the  standard  to  save  money 
or  obtain  non-standard  equipment  with  improved  performance.  Now,  however,  in  digital 
technology  the  government  collectively  may  not  carry  enough  weight  to  impose  standards 
or  insure  a supply  of  spares. 

5.  CONCLUSION 

Future  avionics  system  concepts  will  represent  a significant  departure  from  the  tradition- 
al "black  box"  approach.  Although  significant  advances  have  been  made  in  the  performance 
of  avionics  subsystems,  the  basic  system  organization  has  remained  essentially  constant. 
With  the  advent  of  digital  avionics,  we  are  no  longer  constrained  by  the  traditional 
organization  of  "black  box"  subsystems. 

The  hardware  to  implement  these  new  system  concepts  is  available.  The  major  challenges 
will  be  in  the  areas  of  systems,  software  and  management.  Unfortunately,  experience  has 
shown  that  problems  in  these  areas  tend  to  remain  invisible  until  very  late  in  the 
development  cycle  and  often  continue  well  into  operational  deployment. 

Management  of  these  new  concepts  within  our  own  present  organizational  structure  will 
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require  crossing  system  and  subsystem  boundaries  that  have  been  rigidly  defined  in 
the  past.  This  includes  not  only  those  functions  usually  thought  of  as  avionics,  but 
other  on-board  electronics  functions  such  as  aircraft  flight  control  and  electrical 
systems.  Our  internal  organization  has  tended  to  parallel  the  organization  of  our 
systems  and  subsystems.  Changing  the  system  organization  will  necessitate  cooperation 
between  groups  that  have  very  little  interaction  in  the  past. 

In  addition  to  the  technical  and  management  problems  associated  with  implementing  a new 
system  concept  that  performs  as  expected,  of  equal  importance  are  the  issues  of  standard- 
ization and  interoperability.  To  address  these  issues  requires  cooperation  between 
diverse  groups  within  both  the  DoD  and  NATO.  This  can  be  a slow,  time  consuming  process, 
yet  it  must  be  accomplished  as  an  integral  part  of  the  development,  or  the  resulting 
systems  cannot  be  considered  a complete  success,  regardless  of  their  individual  perform- 
ance. 

The  Navy  approach  to  the  development  of  these  systems  can  be  characterized  by  three  key 
features : 


• We  are  starting  early  with  systems  development  "off-line". 

• We  will  be  using  a structures  design  approach  which  will  stress  simplicity. 

• We  intend  to  perform  extensive  simulation  and  validation  to  insure  that  our 
systems  concepts  are  proven  prior  to  their  use  in  a major  aircraft  development. 

We  can  no  longer  afford  to  be  preoccupied  with  hardware  at  the  expense  of  software.  In 
past  systems  software  was  often  treated  as  just  another  data  item.  Future  systems  plan 
to  use  programmable  hardware  to  the  extent  that  the  "system"  and  its  functions  are 
largely  undefined  without  the  associated  software.  By  approaching  the  systems  issues 
early  and  following  a conservative  approach,  we  hope  to  avoid  many  of  the  problems  of 
past  systems. 
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SUMMARY 

The  advances  in  data  processing  in  the  last  decade  have  been  tremendous.  While  the 
comparable  areas  of  data  acquisition,  displays  and  controls  have  not  made  the  same  order 
of  progress  significant  advances  have  been  made.  This  paper  reviews  this  progress  and 
examines  possible  trends  Active  and  passive  sensor  systems  are  reviewed  as  well  as  the 
display  and  control  technologies  available.  In  particular,  uncooled  FLIR  and  microwave 
radiometry  trends  are  examined  in  the  field  of  data  acquisition  and  CRTs,  LLD  arrays, 
liquid  crystals  and  plasma  panels  are  considered  in  the  display  area.  Examples  are  drawn 
from  the  fields  of  air-to-air  combat  and  RPV  control  to  illustrate  the  differences  and 
similarities  between  tactical  system  requirements  in  different  areas.  These  examples  are 
also  used  to  illustrate  some  of  the  outstanding  problem  areas.  A final  section  describes 
the  need  for  standard  system  description  languages  and  interface  specification  to  aid  the 
total  system  design. 

1.  INTRODUCTION 

The  availability  of  suitable  sensors  and  display  systems  forms  the  major  limitation  on 
the  performance  of  tactical  systems.  The  array  of  processors  and  processing  techniques 
is  now  extremely  formidable  and  in  general  there  are  available  techniques  to  provide 
real  time  processing  capability  to  meet  our  systems  needs  - albeit  at  a high  cost  for 
some  of  the  more  complex  systems. 

As  with  all  systems  however  the  tactical  processing  system  is  only  as  good  as  its  input 
data.  Similarly  unless  the  processed  information  is  displayed  to  the  human  operator  in 
a form  which  he  can  readily  assimilate,  it  is  of  little  value. 

In  the  last  few  years  the  range  of  sensors  available  to  detect  targets  so  that  the 
tactical  situation  can  be  assessed  has  grown  enormously  and  a wide  variety  of  sensors 
are  to  a greater  or  lesser  extent  available.  These  sensors  indeed  cover  the  entire 
field  of  chemical,  physical,  acoustic  and  electromagnetic  measurements  aud  it  is 
obviously  beyond  the  scope  of  this  paper  to  consider  such  a range. 

In  this  paper  therefore  only  the  electromagnetic  sensors  - in  particular  some  of  the 
newer  passive  sensors  - are  considered. 

Display  technology  is  also  in  a state  of  flux  and  a variety  of  new  techniques  are  be- 
coming available.  In  this  field  however,  the  CRT  is  still  pre-eminent  and  forms  the 
standard  against  which  all  displays  are  measured. 

Finally,  there  remains  the  problem  of  display  content  and  two  examples  of  the  possible 
use  of  tactical  displays  are  given. 

2.  SENSORS 

2.1  General 

As  was  mentioned  in  the  introduction,  the  sensors  considered  operate  in  the  electro- 
magnetic region.  For  reference  purposes,  Figure  1 shows  the  frequencies  and  wave 
lengths  of  the  various  parts  of  this  region. 

Most  of  this  spectrum  can  be  surveyed  by  sensors  of  one  sort  or  another  ranging  from 
television  operating  in  the  visual  range  through  radar  systems  operating  at  microwave 
frequencies  down  to  RF  detectors  used  in  the  VHF  and  HF  for  electronic  surveillance 
purposes . 

The  increasingly  hostile  ECM  and  ESM  environment  to  be  anticipated  on  a battlefield  has 
led  to  greater  emphasis  being  placed  upon  the  use  of  passive  techniques  for  surveillance 
and  research  and  development  in  passive  sensors  is  taking  place  using-.- 

a)  low  light  level  television  techniques 

b)  infra  red  techniques 

c)  microwave  radiometry. 


In  addition,  the  advent  of  the  mini  RPV  with  its  potential  for  collecting  tactical 
information  at  low  cost  has  led  to  the  need  for  the  development  of  small  lightweight 
low  cost  sensors. 
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The  three  most  promising  developments  in  this  area  are: 

a)  The  charged  coupled  devices  for  visible  (and  near  infra  red)f requencies 

b)  The  pyroelectric  vidicon  for  infra  red  frequencies 

c)  The  microwave  radiometer  for  microwave  frequencies. 

CCD's  have  been  discussed  extensively  in  recent  years  and  it  is  only  a matter  of  time 
before  semiconductor  technology  provides  devices  with  the  same  (or  even  higher) 
resolution  as  a conventional  camera  tube.  Interesting  though  such  devices  are,  they 
can  be  thought  of  as  solid  state  elements  which  may  ultimately  replace  their  thermonic 
equivalents.  Figure  2 shows  a typical  CCD  structure. 

The  remaining  systems  offer  the  potential  of  providing  low  cost  sensors  for  both 
ground  and  airborne  use  and  as  such  should  be  discussed  further. 

2.2  The  Pyroelectric  Vidicon 

Pryoelectricity  was  one  of  the  many  effects  investigated  by  19th  century  physicists, 
in  this  case  D.  Brewster  and  reported  by  him  in  a paper  published  in  the  Edinburgh 
Journal  of  Science  in  1824. 

The  effect  occurs  in  certain  crystals  which  on  undergoing  a change  in  temperature 
produce  a surface  charge  in  a particular  direction  as  a result  of  the  change  in  its 
polarisation  with  temperature.  Reference  1 describes  this  phenomenon  in  detail. 

All  IR  sensors  must  operate  in  the  IR  windows  of  the  atmosphere  (Figure  3)  and  since 
Planck's  Law  shows  that  black  bodies  at  300°K  have  their  peak  radiation  at  a wavelength 
in  the  region  of  10  microns,  it  is  essential  that  any  imaging  sensor  operates  in  the 
8 to  13  micron  band. 

o 

Of  the  many  pyroelectric  materials  known  , triglycinesulphate  (TGS)  is  the  most  widely 
used. 

Since  a pyroelectric  device  operates  on  temperature  change,  it  is  suitable  for  operation 
as  an  uncooled  thermal  sensor  and  was  proposed  as  such  by  Hadni  in  1965  and  first  pro- 
duced by  Le  Curvennec3  in  1969. 

For  any  uncooled  sensor,  the  following  requirements  must  be  met. 

1.  It  must  operate  above  a reasonable  temperature  range; 

2.  It  should  have  a reasonable  frequency  response; 

3.  It  should  potentially  be  of  low  cost. 

Since  cadmium  mercury  telluride  (CMT)  - which  is  the  other  obvious  candidate  for  an 
uncooled  thermal  imager  - has  a poor  low  frequency  response,  TGS  systems  currently 
appear  the  most  suitable  for  low  frequency  signals.  Figure  4 shows  the  variation  of 
specific  detectivity  D*  with  frequency  for  these  systems  and  it  will  be  seen  that  this 
value  varies  between  about  10^  at  low  frequencies  to  about  10^  at  about  1 KHz.  It 
should  be  noted  that  these  values  D*  are  much  lower  than  those  obtained  from  cooled 
detectors  which  are  of  the  order  of  10^0  to  1011  at  10  am. 

The  pyroelectric  device  itself  is  a vidicon  based  tube  with  a target  made  of  TGS. 

Several  companies  including  English  Electric  Valve,  Philips  and  Heinmann  GMBH  have 
produced  such  tubes. 

As  had  already  been  discussed,  the  pyroelectric  vidicon  operates  on  changes  in  incident 
radiation  and  not  the  radiation  level  itself.  Because  of  this  some  form  of  modulation 
is  required  to  produce  a stable  thermal  image.  The  modulation  systems  most  commonly 
used  are  panning  and  chopping.  The  panning  approach  is  to  use  an  optical  modulator 
and  is  shown  in  Figure  5.  In  this  system,  the  scene  is  panned  backwards  and  forwards 
across  the  target  by  means  of  the  modulator  so  that  the  temperature  is  changed.  The 
resultant  image  is  then  stabilised  electronically.  This  system  gives  good  results, 
but  there  are  several  problems  with  this  approach: 

a)  cooling  wake 

b)  pan  reversal  transients 

c)  loss  of  resolution  in  the  panning  direction. 

The  cooling  wake  problem  is  due  to  the  cooling  of  the  target  after  a heated  region 
vanishes  from  the  field  of  view.  Since  this  is  a negative  temperature  change,  the 
target  responds  and  a negative  image  is  produced  which  has  the  effect  of  masking  any 
small  objects  in  the  field  of  view. 

Pan  reversal  transients  are  due  to  the  thermal  lag  in  the  material.  As  the  panning 
motion  is  reversed,  the  image  persists  (possibly  for  several  cycles)  and  so  causes 
confusion.  This  effect  can  be  minimised  if  continuous  panning  is  performed  and  a 
rotating  prism  is  most  commonly  used  to  perform  this.  Typically,  the  prism  rotates 
at  180°/sec  thus  rotating  the  image  on  the  screen  at  this  frequency.  The  image  is  then 
stabilised  electronically.  The  image  still  however  exhibits  thermal  streaks. 


The  chopping  approach  is  simply  to  apply  optical  modulation  by  means  of  a shutter. 
When  the  shutter  is  closed,  a negative  image  is  produced.  This  image  may  be  inverted 
before  display  to  produce  a second  positive  image  from  the  display. 


Currently,  the  performance  of  pyroelectric  vidicon  is  such  that  minimum  resolvable 
temperature  differences  of  less  than  0.5°C  can  be  detected  and  200  line  TV  performance 
has  been  demonstrated.  Figure  6 shows  the  performance  of  a conventional  TGS  system  and 
that  of  an  alternative  pyroelectric  material  deuterated  tryglycine  f luroberyllate . 

While  it  is  most  unlikely  that  the  performance  of  these  sensors  will  ever  approach  that 
of  the  cooled  thermal  imager,  the  PE  vidicon  is  certainly  approaching  the  state  when  it 
provides  a low  cost  alternative  to  conventional  IR  systems.  As  such,  it  may  find 
substantial  use  particularly  in  mini  RPV's. 

2.3  Microwave  Radiometry 

The  microwave  radiometer  operates  in  the  various  atmospheric  windows  in  the  microwave 
frequency.  Figure  7 shows  these  windows  and  radiometers  are  typically  designed  to 
operate  in  the  35  GHz  region  although  some  work  is  proceeding  at  90  GHz  as  well  as  at 
the  lower  frequencies. 

Such  a radiometer  receives  both  reflected  and  emited  radiation  from  the  scene  and 
Reference  4 shows  some  results  obtained  by  the  Naval  Weapons  Centre  China  Lake. 

Figure  8 shows  in  schematic  form  the  component  elements  of  a radiometer. 

The  antenna  is  typically  the  same  type  as  a radar  operating  at  the  same  frequency 
and  the  essential  requirement  is  to  achieve  as  low  a noise  figure  as  possible. 

In  assessing  the  performance  of  a radiometer,  the  most  important  parameters  are: 

a)  The  target  to  background  radiometric  temperature  difference. 

This  depends  upon  the  reflectivity  and  emissivity  of  the 
target  and  the  apparent  sky  temperature. 


b)  Attentuation  of  the  radiation  from  the  target  by  the 
intervening  atmosphere. 

c)  The  emission  of  the  intervening  atmosphere. 


d)  The  proportion  of  the  radiometer  beam  width  occupied 
by  the  target. 
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Based  upon  these  criteria,  Dicken  and  Wright  have  derived  the  curve  shown  in  Figure  91} 
for  a typical  radiometer.  This  shows  that  even  in  rain,  a radiometer  operating  at 
30  GHz  can  detect  a 10  square  metre  target  at  about  3 KM.  Thus,  in  all  but  the  most 
severe  meteorological  conditions  a radiometer  should  be  capable  of  detecting  a 
stationary  main  battle  tank  at  about  4 to  5 KM.  This  capability  is  of  obvious  importance 
and  because  of  the  passive  nature  of  this  type  of  sensor  coupled  with  its  all  weather 
capability,  it  is  anticipated  that  such  sensors  will  play  an  ever  increasing  role  in 
future  tactical  systems. 

3.  DISPLAYS 

3.1  General 

There  are  now  available  a wide  variety  of  displays  for  use  in  tactical  systems.  In 
order  to  chose  the  most  appropriate  display,  the  following  parameters  are  important: 

1.  Frame  rate 

2.  Contrast  ratio 

3.  Ambient  illumination 

4.  Symbol  characteristics 

5.  Resolution 

6.  Bandwidth 

These  characteristics  are  interdependent  and  for  example  a low  frame  rate  causes  flicker 
unless  either  scan  conversion  or  a long  persistanae  display  medium  is  used.  If  the  latter 
approach  is  taken  then  in  general  the  display  has  low  brightness  and  a poor  contrast 
ratio.  To  avoid  the  flicker  problem  frame  rates  about  30-35  Hz  are  normally  considered 
necessary  although  as  shown  in  Figure  10  this  frequency  varies  with  brightness.  This 
is  true  ior  a single  display,  but  because  the  increased  sensitivity  of  the  peripheral 
vision  of  the  eye  flicker  can  be  observed  up  to  about  50-60  Hz  if  the  display  is  present 
only  in  the  periphery  of  the  operator's  field  of  view.  This  is  of  obvious  importance 
when  an  operator  is  monitoring  not  one  but  several  displays. 

Figure  11  shows  the  frame  rates  of  some  of  the  more  commonly  used  sensors  and  it  will  be 
seen  that  to  provide  a bright  display  with  no  flicker  scan  conversion  is  required. 


Despite  the  advent  of  alternative  displays  such  as  light  emitting  diodes,  liquid  crystals, 


plasma  panels,  etc.,  the  CRT  because  of  its  versatility  and  mature  state  of  development 
is  still  the  dominant  display  in  tactical  systems.  To  illustrate  the  range  of  uses  for 
CRT  displays,  Table  1 indicates  the  most  commonly  used  phosphors  and  some  of  the  appli- 
cations to  which  they  have  been  put. 

3.2  Colour  CRTs 

It  is  somewhat  surprising  that  despite  the  millions  of  colour  TV  systems  in  use  colour 
CRT  displays  are  still  in  their  infancy  for  tactical  systems. 

The  reasons  for  this  are:- 


a)  Colour  CRT  displays  are  low  brightness; 

b)  The  shadow  mask  system  generally  used  in  commercial 
displays  is  a delicate  construction  and  would  not 
meet  the  environmental  requirements  of  most  military 
systems ; 

c)  The  tube  has  limited  resolution; 

d)  There  is  still  some  arguments  as  to  whether  the 
increased  effectiveness  of  colour  in  tactical  displays 
is  cost  effective. 

Of  the  colour  tubes  available,  the  penetron  (Figure  12)  is  the  most  likely  contender 
for  military  applications.  This  tube  has  a limited  range  of  colours  - typically  four 
or  five  - but  enables  some  colour  coding  of  tactical  information  to  be  performed. 

The  cost  of  such  a system  is  of  course  higher  than  that  of  a monocromatic  display 
since  to  achieve  colour,  the  high  voltage  supply  must  be  modulated. 

3.3  Solid  State  Displays 

There  are  a number  of  possible  solid  state  displays  for  use  in  tactical  systems. 

Table  2 shows  some  of  these.  The  main  problems  for  the  use  of  these  displays  are : - 

a)  With  the  exception  of  LEDs  and  LCDs  the  brightness  of 
such  systems  is  low; 

b)  The  cost  of  the  matrix  drive  circuits  currently  makes 
the  total  display  cost  higher  than  that  of  a CRT; 

c)  The  resolution  of  such  systems  is  much  lower  than  a CRT. 

The  best  resolution  obtainable  at  the  moment  is  from  a plasma  panel;  Figure  13 
shows  the  structure  of  such  a panel.  It  has  the  advantages  of  providing  reasonable 
resolution  (500  x 500  elements)  with  a high  contrast  ratio  which  helps  offset  its 
low  brightness. 

The  liquid  crystal  display  offers  a variety  of  advantages  and  has  of  course  no 
brightness  problems.  Considerable  work  on  these  displays  has  been  done  - particularly 
by  Hughes  and  the  early  problems  of  slow  response  and  limited  temperature  range  are  „ 
gradually  being  overcome.  This  type  of  display  has  been  described  in  detail  by  Slocum”. 

Another  display  medium  which  shows  promise  is  the  light  emitting  diode  array.  Many 
materials  exhibit  light  emitting  characteristics  and  Figure  14  shows  the  most  common 
in  relation  to  the  spectral  response  of  the  eye.  A greal  deal  of  work  has  been  carried 
out  on  high  brightness  LED  displays  and  the  Marconi  Company  have  achieved  12000  ft 
lambert  10O  x 100  matrix  displays.  This  work  is  being  carried  out  in  particular  for 
head  up  and  helmet  sight  applications.  The  major  problems  of  such  displays  are  the 
high  currents  needed  to  achieve  high  brightness  and  the  cost  of  the  matrix  drive  elements. 

3.4  Combined  Displays 

One  common  requirement  of  a tactical  display  is  to  present  map  information.  This  can  be 
done  by  a computer  generated  map  and  Figure  15  shows  such  a map.  The  amount  of  map 
detail  which  can  be  stored  on  a computer  is  however  limited  unless  an  extremely  large 
memory  is  provided.  Such  systems  are  not  cost  effective  in  comparison  with  the  type  of 
projected  map  display  developed  for  aircraft  use-  The  early  versions  of  these  displays 
suffered  from  the  problem  that  while  the  fixed  information  (the  map)  was  effectively 
displayed,  the  dynamic  information  could  not  be  superimposed  on  this. 

There  are  two  current  approaches  to  this.  The  first  of  these  uses  a rear  port  tube. 

In  this  approach,  which  is  shown  in  Figure  16  , the  map  is  projected  through  a port  at 
the  rear  of  a CRT  onto  the  face  plate  of  the  tube.  The  CRT  is  then  used  to  write  the 
dynamic  information  onto  the  display. 

An  alternative  approach  has  been  developed  by  Ferranti.  In  this  system,  optical  mixing 
is  used  to  superimpose  the  static  information  on  that  of  a standard  CRT.  This  technique 
is  used  in  the  Tornado  and  F18  aircraft  to  increase  the  flexibility  of  the  projected  map 
displays  used  in  those  aircraft. 
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Trends  in  Future  Displays 


Unlike  the  sensor  area,  the  display  field  is  still  dominated  by  one  technology  - 
the  CRT.  While  other  display  media  have  potential,  they  still  require  considerable 
development  before  they  are  as  cost  effective  as  existing  CRTs.  CRT  technology  is 
not  static  and  the  combined  display  approach  allowing  the  combination  of  static 
information  from  a 35  mm  film  with  dynamic  alpha  numerics  and  symbology  will  increase 
still  further  the  flexibility  of  a CRT.  At  the  same  time,  the  type  of  combined 
display  described  above  could  be  used  with  other  display  media  when  only  limited 
resolution  is  required. 

4.  EXAMPLES  OF  TACTICAL  DISPLAYS 


Thus  far,  this  paper  has  concentrated  upon  technology  rather  than  applications. 

However,  any  system  designer  should  start  with  the  required  application  and  from  this 
decide  the  type  of  technology  needed  to  solve  the  problem. 

In  the  field  of  displays,  as  well  as  the  technology  to  be  used,  great  attention  must 
be  paid  to  the  needs  of  the  operator.  The  field  of  human  factors  is  vast  and  in  general 
is  beyond  the  scope  of  this  paper. 

In  general  however  great  care  must  be  taken  to  present  the  operator  with  the  information 
needed  to  carry  out  his  task.  This  in  a form  which  is  readily  assimilated  by  the 
operator. 

The  type  of  information  needed  depends  upon  the  operational  environment  and  the  time 
which  is  available  to  the  operator  to  assess  the  information.  The  following  para- 
graphs give  some  examples  of  this.  These  examples  do  not  relate  to  any  particular 
system,  but  are  designed  to  present  the  types  of  system  possible. 

4.2  Mission  Planning  in  a ground  environment 

To  examine  the  information  requirements  to  plan  a mission,  the  following  example  is 
considered. 

A remotely  pilotted  vehicle  is  to  be  dispatched  on  an  information  gathering  mission. 

It  is  required  to  prepare  a flight  plan  which  will  cover  the  required  area  and  to 
specify  the  tasks  to  be  performed.  It  may  be  necessary  to  modify  this  flight  plan 
during  the  mission  to  update  the  tasks  to  be  performed  and  to  carry  out  a new  task 
which  has  a higher  priority. 

The  first  set  of  information  needed  by  the  mission  commander  is  the  current  status  of 
the  vehicle.  Figure  17  shows  a possible  CRT  display  which  occupies  only  a portion  of 
the  available  display  area  and  is  always  available  to  the  commander. 

This  data  shows  the  current  location  of  the  air  vehicle,  the  remaining  flight  time, 
the  time  at  which  the  return  flight  should  start,  the  time  the  next  task  should  start 
and  the  duration  of  the  task  as  well  as  a list  of  the  remaining  tasks. 

To  enable  the  mission  to  be  planned,  it  is  necessary  to  consider  a variety  of  information. 
The  approach  taken  is  to  operate  the  system  at  a number  of  different  levels.  A menu 
approach  is  taken  so  that  the  mission  commander  has  maximum  flexibility. 

Figure  ig  shows  the  top  level  of  this  menu.  While  Figure  19  shows  the  next  level. 

Thus,  the  mission  commander  can  input  or  update  intelligence  information,  can  display 
this  data,  can  update  both  the  particular  task  or  mission  etc. 

By  keying  the  intelligence  input,  the  display  format  changes  to  that  shown  in  Figure  20.. 
This  enables  the  commander  to  input  intelligence  data  of  the  type  shown. 

Finally,  the  commander  can  select  a symbolic  mode  (Figure  21  ) which  indicates  the 
location  of  the  forces  as  specified  by  the  intelligence  input. 


With  this  data,  it  is  possible  to  proceed  to  the  mission  planning  stage, 
approach  is  taken  to  specify  the  tasks  required  and  the  flight  plan. 


A similar 


The  final  symbolic  display  is  shown  in  Figure  22  . Although  this  appears  confusing  in 
monocrome,  in  practice  a colour  display  is  used  and  the  tasks  (figures)  and  any  points 
(letters)  are  colour  coded. 

While  it  is  not  the  intention  of  this  paper  to  examine  the  rationale  behind  the  display 
formats  given,  the  following  points  should  be  considered. 


The  menu  approach  taken  is  a powerful  technique.  (It  is 
of  course  standard  for  computer  graphics  applications.) 
However  it  is  possible  only  because  of  the  time  available 
to  the  commander  to  input  the  data  and  to  manipulate  the 
system. 
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2)  This  interactive  approach  is  possible  because  the 
commander  is  able  to  devote  all  of  his  attention  to 
the  task  and  hence  he  is  able  to  consider  the  data 
at  the  various  levels  available  to  him. 

3)  Despite  the  above,  the  approach  of  providing 
different  levels  of  data  so  that  the  operator  is 
given  the  maximum  flexibility  is  valid. 

4)  Great  care  should  be  taken  to  ensure  that  there  is 
maximum  legibility.  Thus,  during  the  mission  itself, 
it  is  possible  to  superimpose  a topographic  map. 

While  this  is  attractive,  it  tends  to  clutter  the  display 
during  the  planning  phase  and  the  symbolic  presentation 
used  is  much  easier  to  understand. 

4.3  Airborne  Tactical  Displays 

The  second  example  considered  is  at  the  other  extreme  from  the  first  example.  In 
the  previous  example,  the  operator  was  able  to  devote  his  whole  attention  to  his 
tactical  task  and  was  in  a reasonably  comfortable  ground  environment. 

Consider  now  the  situation  of  the  single  seat  fighter  pilot.  The  pilot  has  not  only 
to  fly  his  aircraft  but  also  to  search  for  and  identify  targets  and  then  to  decide 
upon  his  attack  tactics.  All  of  this  being  done  in  an  aircraft  which  is  flying  at 
high  speed  so  that  both  the  pilot's  environment  and  the  time  available  for  him  to 
decide  upon  a tactical  plan  is  limited. 

This  problem  is  not  too  difficult  for  a pilot  :f  he  is  faced  with  only  one  potential 
target,  although  even  there  he  is  faced  with  the  problems  of:- 

a)  Identification 

b)  Determination  of  the  best  interception  manoeuvre 

c)  Energy  management 

d)  Fire  control 

e)  Disengagement. 

While  at  the  same  time  monitoring  his  fuel  and  ammunition  state  and  flying  the 
aircraft . 

The  pilot  of  a modern  fighter  therefore  requires  considerable  assistance  to  perform 
this  task  and  unlike  the  previous  example,  he  has  not  the  time  available  to  operate 
interactively  with  the  aircraft  computing  system.  Instead,  the  available  tactics  should 
be  stored  in  the  system  and  the  best  available  shown  to  him  on  a situation  display  as 
well  as  on  a director  display.  The  pilot  is  of  course  allowed  to  override  the  system 
if  there  are  additional  factors  which  are  not  known  to  the  system. 

The  problem  becomes  much  more  difficult  if  there  is  more  than  one  target. 

Consider  the  situation  shown  in  Figure  23.  In  this  case,  the  pilot  is  presented  with 
not  one  but  five  potential  targets.  It  is  assumed  that  the  aircraft  radar  has  pro- 
cessed the  raw  data  so  that  target  speed,  height  and  direction  are  available. 

The  pilot  is  now  faced  with  the  problem  of  planning  his  tactics  against  these 
potential  targets.  He  now  has  to  select  the  best  target  to  attack  and  to  decide 
which  attack  profile  he  should  adopt.  To  do  this,  he  in  fact  needs  more  information. 

One  possible  approach  therefore  is  to  use  the  aircraft  computing  system  to  calculate 
the  target  positions  at  intercept  and  to  classify  the  targets  in  terms  of  time  to 
intercept. 

This  results  in  the  situation  shown  in  Figure  24-  This  display  shows  the  target 
positions  at  the  time  the  first  intercept  would  be  made,  assuming  that  the  targets 
maintain  their  current  tracks  and  speed.  The  situation  display  is  obviously  updated 
continuously. 

The  pilot  is  then  able  to  see  that  if  he  uses  a rear  hemisphere  attack  on  target  1 
he  will  pass  in  front  of  target  2 and  so  present  that  aircraft  with  a firing 
opportunity.  This  in  turn  means  that  either  he  should  carry  out  a front  hemisphere 
attack  on  target  1 and  then  engage  target  2 or  engage  target  2 in  a rear  hemisphere 
attack. 

The  pilot  having  selected  the  target,  the  system  provides  him  with  steering  information 
to  engage  that  target  while  the  situation  display  continues  to  show  the  projected 
positions  of  the  remaining  targets  during  the  attack.  The  pilot  is  thus  able  to  monitor 
the  situation  and  to  consider  any  threats.  In  particular,  the  display  should  indicate 
any  targets  which  are  moving  into  his  rear  hemisphere  where  the  system  will  no  longer 
be  able  to  track  them. 
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A further  problem  arises  however  when  the  targets  are  of  different  types  and  indeed 
when  some  are  potentially  friendly.  In  these  circumstances,  the  pilot  may  find  that 
he  is  drawn  out  of  position  by  a friendly  aircraft  and  thus  hostile  aircraft  are  allowed 
to  penetrate.  Alternatively,  he  may  find  himself  committed  to  attack  an  enemy  escort 
fighter  and  thus  allow  enemy  attack  aircraft  to  continue  their  mission. 

To  avoid  this  situation,  assuming  that  a long  range  visual  identification  system  is 
carried,  the  system  should  compute  a track  which  allows  the  pilot  to  fly  such  that  he 
is  able  to  identify  visually  each  target  in  turn  without  precluding  attacking  the 
other  (as  yet  unidentified)  targets. 

Figure  25  shows  the  situation  when  targets  1,  2 and  3 are  identified,  the  dotted 
circles  showing  the  limits  of  the  postulated  visual  identification  system.  This 
display  is  of  course  cluttered  and  in  practice  a display  such  as  that  shown  in 
Figure  26  is  preferable.  This  shows  his  projected  track  and  the  points  at  which 
various  targets  come  within  visual  identification  range  along  that  track.  Once  again 
the  system  provides  director  information  to  enable  the  pilot  to  fly  such  a track  and 
continuously  updates  the  situation  display  shown. 

Once  again,  it  is  not  intended  to  suggest  that  this  is  the  best  possible  approach 
to  the  problem,  but  to  illustrate  some  of  the  problems  of  tactical  displays. 

In  this  particular  case,  there  is  limited  decision  time  available  and  the  operator  is 
not  able  to  interact  with  the  computing  part  of  his  system  in  the  same  way  as  the 
operator  in  the  first  system.  Indeed,  the  pilot  need  not  be  aware  that  he  is  operating 
a computer  any  more  than  he  needs  to  know  that  he  is  interacting  with  the  world's 
largest  switching  network  when  he  makes  a telephone  call. 

5.  FUTURE  TACTICAL  SYSTEMS 

Having  discussed  albeit  briefly  the  sensor  and  display  requirements  of  tactical  systems, 
it  is  of  interest  to  consider  the  future  requirements  of  such  systems.  As  was  stated 
in  the  introduction,  the  processing  power  now  available  is  tremendous  and  can  provide 
very  sophisticated  tactical  data. 

The  technology  of  sensors  and  displays  while  not  so  all  embracing  as  that  of  the 
processor  is  still  very  sophisticated. 

There  is  however  a tendency,  particularly  among  the  computer  designers  to  consider 
the  remaining  elements  in  the  system  as  peripherals.  This  is  a dangerous  avenue  of 
thought  since  the  system  is  a total  entity  and  should  be  considered  as  such.  Indeed, 
there  are  more  difficulties  and  problems  to  be  solved  in  the  area  of,  for  example, 
sensors  than  in  the  processor. 

One  of  the  major  problems  to  be  solved  therefore  is  how  to  rationalise  the  system  design 
of  6-rge-scale  tactical  systems.  While  this  has  been  addressed  in  terms  of  the  processor 
and  in  particular  the  software  of  the  processor,  it  is  by  no  means  solved  even  in  that 
limited  area. 

The  overall  system  design  is  still  very  much  emperical  and  there  is  a need  to  further 
develop  system  design  and  specification  tools. 

One  of  the  more  promising  techniques  is  the  ’prototyping’  approach  where  a very  power- 
ful and  flexible  computer  model  is  constructed  of  the  system.  This  enables  various 
alternatives  to  be  considered  before  the  system  design  is  frozen. 

For  this  approach  to  be  effective  however  additional  design  tools  must  be  developed. 

In  particular,  a ’system  description  language’  should  be  produced  which  enables  the 
essential  hardware  and  software  attributes  of  a system  element  (including  its  interface) 
to  be  simply  and  unambiguously  defined.  Such  a language  should  allow  the  system  model 
to  be  constructed  and  modified  quickly  and  when  a satisfactory  system  is  established 
should  enable  clear  and  unambiguous  specifications  to  be  produced.  Some  work  has  been 
done  in  this  field  - notably  by  TRW  in  the  US  and  by  AUWE  and  Plessey  in  the  UK,  but  a 
great  deal  more  needs  to  be  done.  Without  such  tools,  the  capability  of  future  tactical 
systems  will  be  dictated  not  by  technology  limitations  but  by  the  problems  of  system 
design  and  management.  It  is  not  suggested  that  the  above  approach  will  solve  these 
problems,  but  it  should  enable  a more  rational  and  integrated  approach  to  the  design 
of  future  tactical  systems. 
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BASIC  RELATIONSHIPS:  E = hv  v = X/c  c = 2-998  10*8 ms~1 

E = hc/X  = 1-24  10"6/X  eV 

Figure  1 Wave  lengths  and  frequencies  of  EM  spectrum. 
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Figure-..  11  Frame  rates  of  various  sensors 
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Figure  13  Plasma  panel  construction 
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Figure  14  Light  emitting  diode  spectral  response 
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Figure  15  Computer  generated  map 
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Figure  16  Rear  port  tube  schematic 


Figure  24  Projected  situation  at  first  intercept 
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Figure  26  Target  situation  display 


Characteristics  of  Phosphors  Commonly  used 
in  ATC  Displays 
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DISCUSSION 


J .Wild 

What  reduction  in  storage  is  achieved  by  the  use  of  the  bi-arc  technique  for  map  drawing,  and  what  sort  of  processing 
power  is  required  to  produce  the  map  shown. 

Author's  Reply 

The  reduction  obtained  is  obviously  a function  of  the  map  complexity.  Typical  figures  are  85  to  95%  reduction  in 
data  storage.  The  work  was  done  using  an  1CL  1903  in  multi-access  mode.  No  estimates  have  been  made  so  far  for 
the  real-time  computer  power  required. 

J.Wild 

1 should  like  to  make  two  comments:  The  first  concerning  Penetron  displays.  Today  the  resolution  is  as  good  as 
monochrome  displays  and  the  brightness  adequate  for  operations  rooms.  The  second  concerning  DC  Electro- 
luminescent displays.  It  is  now  possible  to  obtain  displays  whose  elements  number  an  order  of  magnitude  greater 
than  the  35  given  in  this  paper. 

Author’s  Reply 

The  Penetron  display  is  adequate  for  low  to  medium  ambient  lighting  conditions.  It  should  be  noted  that  the 
Trinatron  is  now  being  used  in  weather  radar  displays  and  this  tube  may  be  even  more  attractive. 

I agree  to  your  second  comment.  The  table  given  was  produced  several  months  ago  based  upon  published  data  at 
that  time. 


D.  Bosnian 

Could  you  report  on  the  acceptance  by  the  operator  or  pilot  of  the  new  display  technologies,  the  new  data  presenta- 
tion techniques  and,  in  some  cases,  the  ensuing  implications  for  task  structure? 

Author’s  Reply 

This  is  difficult  to  answer  without  going  into  a lot  of  detail.  In  general  for  the  first  example  given,  some  operator 
feedback  is  being  obtained,  but  it  will  be  sometime  before  sufficient  data  is  available  for  a meaningful  analysis. 
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THE  REAL-TIME  TACTICAL  RECONNAISSANCE  DATA  HANDLING  PROBLEM 

Henry  Lapp 
AFAL/RWI 

WPAFB,  Ohio  45433 
SUMMARY 

An  important  role  for  airborne  reconnaissance  is  the  location  and  identification  of  targets  in  near 
real  time.  Current  technology  has  been  compartmented  into  sensors,  data  links,  processing,  ground 
exploitation  and  finally  dissemination.  In  the  days  of  bring  home  reconnaissance,  this  segmentation  of 
functions  was  appropriate.  However,  with  the  current  emphasis  on  near  real-time  intelligence,  this 
thinking  has  to  be  reanalyzed.  A total  systems  approach  to  data  management  must  be  employed  using  the 
constraints  imposed  by  the  atmosphere,  survivable  flight  profiles  and  jamming.  This  paper  will  analyze 
the  target  acquisition  through  classification  tasks  and  discuss  the  machine  processing  and  data  screening 
techniques  that  are  applicable.  The  data  handling  capabilities  of  an  on-board  operator  and  ground  based 
image  interpreter  are  compared.  A philosophy  of  processing  data  to  get  information  as  early  as  possible 
in  the  data  handling  chain  is  examined  in  the  context  of  ground  exploitation  and  dissemination  needs. 
Examples  of  how  the  various  real-time  sensors  (screeners  and  processors)  could  fit  into  this  data  handling 
scenario  are  discussed.  Specific  unclassified  DOD  programs  will  be  used  to  illustrate  the  credibility 
of  this  integrated  approach. 


THE  NEED  FOR  RAPID  RECONNAISSANCE 


Since  the  Blitzkrieg  type  of  warfare  was  successfully  demonstrated  in  World  War  II,  the  mobility  of 
ground  forces  has  constantly  increased.  It  is  now  possible  for  very  large,  well  equipped,  full  spectrum, 
ground  forces  to  overrun  defenses  and  thrust  from  tens  of  kilometers  to  a hundred  or  more  kilometers  per 
day,  obtaining  and  maintaining  control  of  the  entire  area  encompassed,  or  to  rapidly  deploy  in  preparation 
for  an  attack.  Suffice  to  say  the  battlefield,  as  well  as  the  domain  of  air  operations,  can  be  extremely 
fluid. 

It  is  the  prime  purpose  of  tactical  reconnaissance  to  provide  the  theater  and  the  field  commanders 
with  the  necessary  information  about  the  enemy's  operational  situation  to  successfully  conduct  operations, 
both  air  and  ground,  in  such  a fluid  environment.  Obviously,  this  information  must  be  timely. 

When  the  enemy  has  the  prerogative  and  the  opportunity  to  conduct  offensive  operations,  the  need  for 
timely  information  becomes  increasingly  critical.  The  defense  must  effectively  react  while  the  opportunity 
is  available  or  before  it  is  too  late  and  their  capability  to  do  so  is  overrun  or  otherwise  negated.  In 
this  type  of  highly  mobile  warfare  tactical  aerial  reconnaissance  plays  a vital  role,  being  the  most 
mobile  of  all  capabilities.  A reconnaissance  aircraft  can  travel  at  a rate  of  18  kilometers  per  minute 
or  more,  permitting  it  to  reach  an  area  of  concern  from  a remote  base  in  a few  minutes.  It  can  cover  a 
substantial  area  of  concern  in  a few  seconds.  The  crux  of  the  problem  is  to  make  the  information,  so 
quickly  gatherable,  useful  in  time  for  reaction.  To  date  this  has  been  effectively  accomplished  too 
infrequently. 

Traditionally,  airborne  reconnaissance  has  been  accomplished  by  a reconnaissance  vehicle  flying  over 
the  area  of  interest.  A variety  of  sensors  aboard  the  vehicle  sense  and  record  the  reconnaissance  informa- 
tion for  subsequent  processing,  interpretation  and  reporting  of  the  digested  information.  These  functions 
normally  occur  upon  landing  at  the  reconnaissance  base.  The  time  involved  in  this  total  process,  from 
sensing  to  reporting,  varies  from  hours  to  weeks,  depending  upon  the  type  of  missions  and  the  quantity  of 
data  sensed  (the  extent  of  the  coverage  and  the  resolution),  and  the  type  of  information  to  be  extracted. 
This  time  factor  can  be  broken  down  into  functions  as  follows: 

Air  Transportation  - Time  for  the  vehicle  to  return  to  base  and  land.  (Typically  10  min.  to  1 hour) 

Ground  Transportation  - Time  to  transfer  the  recordings  from  the  vehicle  to  a ground  processing 
station.  (5  to  20  min.) 

Data  (or  Image)  Reduction  - Time  to  process  the  recordings  into  extractable  form.  (10  min.  to  2 
hours) 

Target  Detection  and  Location  - Time  to  find  probable  targets/areas  of  interest  in  the  total  recorded 
take.  (2  min.  to  hours) 

Intelligence  Interpretation  - Time  to  interpret  the  recordings  into  applicable  information.  (5  min. 
to  days,  or  weeks  in  the  case  of  maps).  This  usually  involves  correlation  with  other  information. 

Reporting  - Time  for  reporting  procedures  (Preparation,  Dissemination).  (A  few  min.  to  hours,  days 
for  maps) 

The  above  time  factors  are  typical  or  average  values.  They  may  be  significantly  less  for  some 
reconnaissance  missions  where  the  number  of  specific  targets  to  be  reconnoitered  is  small  and  urgency 
procedures  can  be  applied  throughout  the  cycle.  For  missions  in  which  the  information  perishability 
factor  is  an  hour  or  more,  traditional  capabilities  are  adequate  to  solve  the  problem.  They  will  continue 
to  provide  the  bulk  of  the  reconnaissance  and  intelligence  information  obtained.  However,  for  reconnais- 
sance of  more  perishable,  or  more  urgent  targets,  the  normal  reconnaissance-intelligence  cycle  must  be 
drastically  compressed  or  significantly  changed  into  a real  or  near  real-time  reconnaissance  capability 
in  order  to  be  responsive  to  a highly  mobile  threat. 

The  functions  of  target  detection,  location  and  interpretation  normally  involve  the  human  eye  and 
brain  processes  which  are  not  amenable  to  significant  time  compression.  Consequently,  for  near  real-time 
operation,  those  reconnaissance  jobs  requiring  substantial  human  study  must  not  be  undertaken  or  the 
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process  will  rapidly  outgrow  Its  required  time  frame.  The  amount  of  information  for  which  the  human  Is 
tasked  should  be  no  more  extensive  than  that  absolutely  required  for  the  primary  purpose  of  the  mission. 

Only  answers  to  simple  and  precise  reconnaissance  questions  can  be  expected  from  a human  observer  in  real 

or  near  real  time.  It  follows  that  real  and  near  real-time  methods  should  only  be  applied  to  obtain  the 

minimum  information  essential  to  make  a decision  where  rapid  response  is  likely  to  be  required. 

o 

The  historical  method  of  gathering  data  is  with  a film  camera.  A film/camera  data  rate  of  10  is  not 
uncommon.  For  the  real-time  case,  a sensor  data  rate  of  10&  to  10?  pixels  per  second  as  experienced  in 
typical  tactical  scenarios.  This  pixel  rate  number  is  arrived  at  from  convoluting  the  ground  resolution, 
swath  width  and  V/H  necessary  to  adequately  perform  the  tactical  mission.  The  human  in  the  interpretation 
task  has  a 105  data  processing  rate  (Gardiner  and  Nicholson,  1971). 

Because  of  the  limited  amount  of  information  which  a human  can  handle  in  real  or  near  real  time,  and 
the  tremendous  amount  of  data  which  a sensor  can  acquire  in  real  time,  a human  observer  in  the  reconnais- 
sance aircraft  may  well  miss  or  overlook  very  important  information  which  may  not  be  quite  as  time  sensi- 
tive as  that  of  Initial  prime  concern.  For  this  reason,  as  well  as  for  verifying  the  airborne  interpreta- 
tions, it  is  important  that  permanent  recordings  be  made  of  all  sensed  information  for  more  thorough 

assessment  after  return  to  base,  even  though  the  intent  of  the  mission  is  one  of  obtaining  a specific  real 
or  near  real-time  reconnaissance  answer. 

OPERATION  ASPECTS  OF  REAL-TIME  RECONNAISSANCE 

The  traditional  reconnaissance  information  process  cycle  was  broken  into  steps  and  defined.  They  are 
repeated  here  for  convenience: 

1.  Air  Transport  2.  Ground  Transport  3.  Data  Reduction 

4.  Target  Detection  and  Location  5.  Intelligence  Interpretation  6.  Reporting 

The  use  of  a wide  band  data  link  makes  possible  the  elimination  of  several  of  the  above  reconnaissance 
cycle  steps  and  the  possible  reduction  of  the  time  factors  of  others.  For  example,  if  the  data  link  can 
operate  directly  from  the  reconnaissance  vehicle,  while  it  is  acquiring  the  information,  and  can  transmit 
at  the  acquisition  rate,  then  steps  1 and  2 above  are  eliminated.  In  addition,  step  3 can  be  reduced  by 
operating  the  recorder-processor  in  tandem  with  the  receiver,  at  the  information  acquisition  rate.  Rapid 
film  processing  technology  can  reduce  step  3 to  under  two  minutes,  under  special  conditions  to  as  low  as 
10-15  seconds.  Even  if  the  reconnaissance  aircraft  cannot  transmit  while  acquiring,  a buffer  storage  can 
be  provided  in  the  aircraft  to  permit  transmission  when  the  aircraft  reaches  a position  from  which  it  can 
transmit.  This  will  not  elirainite  step  1 but  will  reduce  it  considerably;  step  2 will  still  be  eliminated: 
and  step  3 will  be  reduced  as  above.  Step  3 can  be  reduced  to  zero  by  use  of  a dynamic  display  of  the 
information  instead  of,  or  in  parallel  to,  the  recorder. 

For  steps  4,  5 and  6,  the  human  is  normally  involved  and  reduction  of  time  elements  for  these  steps 
can  only  be  reduced  by  changing  his  duties.  The  time  required  is  a function  of  the  area  covered  by  the 
reconnaissance  per  unit  time,  the  number,  size  and  deployment  of  targets  of  concern,  other  target  charac- 
teristics such  as  smok^,  dust,  or  tracks,  the  ability  to  extract  the  pertinent  information  from  the  scene 
(clutter,  contrast),  the  number  of  interpreters  employed,  the  skill  and  experience  of  the  interpreters, 
and  the  procedures  used.  The  target/background  characteristics  (such  as  clutter  and  contrast)  are  always 
dominant  factors. 

Real  and  near  real-time  transmission  of  reconnaissance  imagery  can  thus  reduce  the  total  time  factor 
between  acquisition  of  the  reconnaissance  and  reporting  to  a matter  of  approximately  ten  minutes  up  to  an 
hour  or  so.  Wide  band  data  transmission  is  thus  most  useful  for  information  whose  perishability  factor 
is  in  this  time  range.  However,  this  conclusion  is  valid  only  when  the  human's  time  factors  do  not 
dominate  the  equation.  Otherwise,  the  process  becomes  swamped,  quickly  breaks  down,  and  is  useless. 

For  operation  in  a high  jamming  environment  or  line  of  sight  conditions  where  a wide  band  data  link 
capability  may  be  unuseable,  the  same  results  can  be  achieved  with  a dynamic  display  for  the  reconnaissance 
crew  in  the  reconnaissance  vehicle  and  having  them  perform  the  entire  process  and  report  via  a narrow  band 
link.  The  reconnaissance  cycle  time  is  thus  reduced  to  the  time  required  for  the  reconnaissance  crew  to 
detect  and  recognize  (interpret)  the  targets  and  verbally  or  symbolically  report  their  findings.  Within 
certain  constraints,  this  can  be  a matter  of  seconds. 

If  the  reconnaissance  crew  is  delegated  the  authority  to  make  strike  decisions,  it  is  now  a recon- 
naissance/strike capability.  This  reconnaissance/strike  process  has  been  accomplished  for  many  years  for 
a limited  range  of  applications  and  under  restrictive  conditions.  The  traditional  forward  air  controller, 
operating  in  low-performance  aircraft,  is  an  example  of  the  entire  process  which  usually  includes  decision 
making  and  direct  or  indirect  control  (target  designation)  of  strikes.  Until  recently,  the  principal 
reconnaissance  sensor  of  the  forward  air  controller  has  been  the  human  eye,  unaided  or  aided  with  various 
types  of  visual  optical  sights.  In  addition,  a substantial  amount  of  reconnaissance  information  has  been 
collected  visually  by  strike  pilots  as  an  adjunct,  or  in  addition,  to  their  primary  strike  missions.  In 
these  cases,  the  process  has  been  in  real  or  near  real  time  although  no  reconnaissance  sensors  nor  displays 
of  pictorial  reconnaissance  information,  per  se,  were  necessary.  However,  the  conditions  of  operation  have 
been  restricted  to  daylight  and  good  visibility. 

Sensor  technology  now  permits  the  reconnaissance  capability,  as  well  as  that  of  the  forward  air 
controller,  to  be  extended  to  nighttime  operation  and/or  conditions  of  visibility  well  beyond  the  eye's 
unaided  capability.  In  addition,  depending  on  the  scenario,  the  near  real-time  reconnaissance  or  forward 
air  controller  capabilities  may  be  accomplished  from  high  performance  aircraft.  In  these  cases  the  target 
rate,  clutter  and  contrast  become  more  and  more  important.  While  much  work  is  progressing  to  model  and 
and  quantify  the  effect  of  the  physical  variables  on  the  human  performance  of  detecting  and  recognizing 
targets  at  real-time  rates,  the  variables  are  so  complex,  numerous  and  interrelated  that  the  problem 
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cannot  be  generalized.  The  remainder  of  this  paper  will  discuss  techniques  to  assist  in  the  real/near 
real-time  performance  of  sensors/humans  to  perform  reconnaissance  missions  and  the  operational  limitations 
of  such  techniques. 

One  of  the  prime  functions  of  aerial  reconnaissance  is  to  maintain  periodic  surveillance  of  a large 
area  of  concern  to  alert  the  commander  to  enemy  activity  or  movements.  As  these  missions  must,  of 
necessity,  be  flown  at  high  altitudes  in  order  to  survey  wide  areas,  line  of  sight  to  the  receiving 
station  (ground  or  airborne)  can  be  achieved.  Use  of  directive  and  tracking  antennae  reduces  the  suscep- 
tibility to  jammers  not  directly  or  nearly  in  the  line  of  sight.  Only  an  airborne  jammer  nearly  in  the 
line  of  sight  can  effectively  jam  the  receiver  and  thus  the  transmission. 

For  the  surveillance  mission,  where  activity  is  the  prime  factor  of  interest,  targets  need  not  be 
recognized  as  such.  Just  changes  or  movements  or  other  unique  features  of  detected  objects  need  be 
observed.  Of  course,  the  objects  detected  must  have  a high  probability  of  being  of  military  significance, 
or  this  relationship  must  somehow  be  deduclble.  For  this  purpose  cues  can  be  used.  The  most  readily 
available  cues  are: 

1.  Motion  (MTI  Radar) 

2.  Change  Detection  (Radar) 

3.  Electromagnetic  Emissions 

4.  Heat  Emissions  (Infrared  Sensor,  weather  permitting) 

Obviously  the  degree  of  normal,  non-military,  activity  of  the  surveyed  area  must  be  relatively  low.  A 
convoy  of  military  vehicles  on  a busy  highway  will  be  detected  but  only  supplemental  information  will 
differentiate  them  from  normal  civilian  traffic.  On  a little  used  secondary  road,  however,  the  appearance 
of  many  moving  objects  would  be  cause  for  alert. 

In  any  case  the  decision  of  where  and  how  to  react  will  probably  require  a specific  reconnaissance 
mission  to  determine,  through  recognition,  what  the  motion  or  activity  really  means.  The  most  useful 
purpose,  then,  of  a surveillance  mission  Is  to  highlight  points  or  small  areas  for  more  detailed  coverage, 
as  well  as  to  provide  alert  warning.  As  this  mission  is  accomplished  from  high  altitude  and  covers  large 
areas,  radar,  either  MTI  or  side  looking-synthetic  aperture,  or  more  desirably  a combination  of  both,  can 
provide  an  all-weather  surveillance  capability  of  wide  areas  for  activity  indication  and  alert  purposes. 

The  information,  either  raw  or  partially  processed,  may  be  linked  to  the  ground  via  wide  band  data  link 
and  automatically  processed  into  Imagery  for  manual  read  out.  If  provided  in  digital  form,  the  informa- 
tion may  be  automatically  compared  to  information  from  a previous  pass  of  the  same  area  in  a digital 
change  detector  with  all  changes  superimposed  on  the  radar  map.  Such  a radar  surveillance  capability 
may  be  augmented  with  electronic  reconnaissance  and/or  infrared  for  the  detection  of  targets  with  those 
specific  characteristics.  For  an  analog  system  the  human  is  required  to  look  at  imagery  and,  depending 
on  the  situation,  could  soon  take  so  much  time  as  to  obviate  the  advantages  of  real-time  transmission. 
Automatic  digital  change  detection  can  overcome  this  limitation,  and  provide  the  necessary  movement 
information  within  the  allowable  time. 

For  detailed  examination  of  specific  points,  small  areas  or  routes  which  have  been  highlighted  by 
surveillance  missions,  or  other  sources,  as  requiring  closer  scrutiny,  specific  reconnaissance  sorties 
are  needed  to  provide  the  necessary  information.  Today's  state-of-the-art  in  automatic  target  identifica- 
tion is  not  sufficiently  advanced  to  preclude  the  need  for  human  recognition  of  targets  on  which  to  base 
strike  decisions  or  tactical  employment  commitment.  This  is  not  to  say  that  exigencies  of  the  situation 
may  not  require  action  based  on  such  a dearth  of  confirmatory  information.  The  operational  situation  may 
be  critical  enough  to  "blast  every  blip  in  sight"  but  in  the  absence  of  the  need  for  such  desperate 
measures  it  seems  fair  to  assume  that  commanders  will  require  more  positive  identification,  based  upon 
recognition  or  at  least  reliable  classification,  before  major  commitment  of  resources.  Automatic  classifi- 
cation techniques,  discussed  later,  are  under  development,  but  accuracy,  completeness  and  low  enough 
false  alarm  rates  for  operational  reliance  have  yet  to  be  flight  demonstrated  and  proven. 

As  humans  must,  as  yet,  do  the  recognizing  of  targets,  this  must  predominantly  be  done  by  virtue  of 
the  shape  and  size  of  the  target.  Today's  radars  or  microwave  sensors  do  not  provide  sufficient 
resolution  for  recognition  of  most  tactical  targets  by  their  shape.  Their  resolution  is  improving  (with 
complications)  but  many  unanswered  problems,  such  as  specularity,  susceptibility  to  electronic  counter- 
measures, etc.,  need  resolution.  Thus  the  primary  recognition  sensors  (other  than  direct  eyeball)  must 
now  be  electro-optical  or  infrared  imagers  which  present  visual-like  information  to  the  human.  Operating 
in  the  optical  wavelengths  (less  than  300  micrometers),  these  sensors  are  susceptible  to  atmospheric 
degradations.  They  cannot  operate  through  clouds  so,  in  the  presence  of  cloud  cover,  they  must  be  used 
below  the  ceiling.  Also,  due  to  atmospheric  haze,  sensor  performance  improves  as  the  distance  to  the 
target  is  decreased.  Sometimes  (in  heavy  fog)  they  are  totally  ineffective. 

The  atmosphere  factors,  plus  the  current  trend  of  flying  very  low  to  survive  in  today's  high  threat 
environment,  dictate  that  this  type  of  reconnaissance  mission  be  performed  at  low  altitude. 

Low  altitude  operation  over  hostile  territory  poses  two  very  severe  problems  for  wide  band  data 
links.  Such  links  require  line  of  sight  from  the  transmitting  aircraft  to  the  receiver.  If  the  trans- 
mitting aircraft  is  at  low  altitude,  terrain  masking  prohibits  the  maintenance  of  line  of  sight  to  a ground 
receiver.  The  receiver,  either  as  a relay  or  as  the  interpretation  station,  must  be  at  high  altitude. 

Such  a receiver  is  highly  susceptible  to  jamming  by  very  unsophisticated  means.  Its  overall  operating 
cost  is  high  and  it  is  a lucrative  target  for  direct  attack.  Even  if  the  receiving  station  employs  highly 
directional  antennae  tracking  the  transmitting  reconnaissance  aircraft,  if  the  jammer  is  anywhere  in  the 
vicinity  of  the  reconnoitered  target  area,  then  the  jamming  can  only  be  overcome  by  one  of  the  following: 

a.  Recording  the  reconnaissance  data  for  transmission  when  the  reconnaissance  aircraft  proceeds 


away  from  the  Jammers  (if  it  climbs  to  high  altitude  then  it  can  transmit  directly  to  the  ground,  as  does 
the  surveillance  mission,  and  a relay  is  not  required  but  the  highly  directional  tracking  receiving  antenna 
is). 


b.  Transmitting  a moderate  information  band  width,  over  a very  high  transmission  band  width 
digital  data  link  while  using  sophisticated  digital  processing  techniques  to  overcome  the  jamming.  This 
restricts  the  transmitted  information  band  width  to,  at  best,  several  hundred  kilobits  per  second  (a  high 
altitude  receiver  with  directional  tracking  antenna  is  still  required). 

c.  Observing  the  target  areas  and  interpretation  of  the  target  situation  by  the  reconnaissance 
crew  with  direct  or  subsequent  reporting  over  a narrow  bandwidth,  jam  resistant  (possibly  secure),  digital 
data  link  by  voice,  symbology,  or  very  limited  pictorial  coverage. 

CUEING  AND  AUTOMATIC  SCREENING  AND  TARGET  CLASSIFICATION 


Cueing  for  the  wide  area  surveillance  mission  has  already  been  discussed.  Use  of  autonomous  cueing, 
screening  or  target  classification  techniques  on  specific  reconnaissance  missions  would  enhance  the  search 
capability  considerably  to  accomplish  reacquisition  of  targets  which  have  moved,  or  to  overcome  positional 
errors  in  either  the  original  target  location  or  in  the  navigation.  They  may  even  provide  some  capability 
for  finding  targets  of  opportunity.  If  the  cueing  technique  is  automatic  the  reconnaissance  crew  or  the 
ground  interpreters  are  assisted  in  the  search  function  (a  function  which  the  human  does  very  poorly  but 
machines  can  do  well)  and  permits  their  concentration  on  the  recognition  and  identification  functions 
(which  machines  do  poorly  but  humans  do  well).  Several  cueing  techniques  will  be  discussed  below,  along 
with  their  applications  in  conjunction  with  an  identification  sensor  to  provide  a localized  search/ 
identification  capability.  These  cueing  techniques  are  highly  target  dependent.  Specific  unique  target 
characteristics  are  used  and  false  alarm  (non-targets  with  similar  unique  characteristics)  rates  are 
constantly  a problem.  While  clutter,  without  target-like  characteristics,  is  no  problem,  in  a highly 
target  rich  environment  cuers  will  only  indicate  the  fact  that  there  are  a lot  of  targets  or  target  like 
things.  In  this  case,  selection  of  a particular  cued  target  for  identification  must  be  either  manual  or 
random . 


CUEING  USING  THE  IDENTIFICATION  SENSOR 


Infrared  Cues.  Under  many  conditions  certain  types  of  targets  emit  strong  infrared  radiation  by 
virtue  of  their  temperature/emissivity  characteristics.  These  emissions  may  be  detected  at  long  range  by 
a FLIR  operating  in  the  "wide"  angle  mode  near  the  horizon,  although  target  masking  by  terrain  or  foliage 
may  be  a problem.  With  a 20°  field  of  view  the  sensor  may  be  "panned"  slowly  across  the  forward  horizon 
for  the  detection  of  such  emissions.  Upon  detection  the  narrow  angle  of  the  FLIR  may  be  employed, 
centered  on  the  "hot  spot"  and  closure  employed  until  recognition.  In  the  case  of  a downward  looking 
infrared  sensor,  hot  spots  on  the  imagery  automatically  draw  attention  to  specific  points  and  their 
immediate  surrounds.  While  hot  spot  cueing  is  inherent  in  an  infrared  sensor,  it  is  not  effective  if  a 
prolif ication  of  hot  spots  appear. 

Automatic  Screening.  Considerable  work,  with  some  success,  has  been  accomplished  on  applying  auto- 
matic screening  techniques  to  analog  video  signals,  especially  from  infrared  sensors  (both  line  scan  and 
FLIR).  Simple  algorithms  have  been  developed  to  detect  targets,  with  the  first  iteration  being  on  edges 
and  lines  characteristic  of  man-made  objects  and  further  refinement  being  made  on  size  and  geometry.  The 
screener  divides  a FLIR  frame  or  section  of  a strip  of  line  scan  coverage  into  small  areas  and  indicates 
which  of  the  smaller  areas  does  or  does  not  contain  man-made  objects.  The  further  refinements  discard 
such  man-made  objects  as  roads  and  large  buildings.  Detection  probabilities  on  vehicles  have  been  high, 
but  false  alarm  rates  are  highly  dependent  on  the  background  due  to  the  fact  that  features  of  vehicles 
(size,  aspect  ratio,  etc.)  used  in  the  screening  process  are  the  same  as  those  of  some  non-vehicle  man- 
made objects  of  no  interest.  The  principal  virtue  of  this  technique  is  that,  in  real  time,  it  automatically 
discards  areas  of  a scene  wherein  the  probability  of  there  being  a man-made  object  is  low,  thus  improving 
search  time  by  a human.  However,  in  a highly  cluttered  urban  scene  very  little  is  discarded,  limiting 
the  usefulness  of  this  technique  to  rural  or  natural  backgrounds.  The  screener  output  may  be  superimposed 
symbolically  on  the  observer's  display  and/or  record  either  in  the  cockpit  from  a FLIR  or  line  scan  sensor, 
or  at  the  receiving  station,  to  highlight  those  small  areas  where  the  probability  of  there  being  a target 
is  high. 

The  USAF  Avionics  Laboratory  is  currently  pursuing  this  technology  for  FLIR  applications.  The  current 
progress  represented  by  an  average  false  alarm  rate  of  less  than  5%  and  a probability  of  detection  greater 
than  902.  This  performance  is  considered  promising  enough  for  us  to  go  forward  with  an  airborne  version 
next  year. 


CUEING  USING  A SEPARATE  SENSOR 


Radar.  If  the  specific  reconnaissance  aircraft  has  a radar  capable  of  detecting  military  targets  plus 
an  MTI  capability,  it  can  provide  cues  on  which  to  point  the  TV  or  FLIR  sensor  for  recognition  and 
identification  or  to  mark  the  line  scan  imagery.  The  radar  must  be  capable  of  acquiring  targets  at  low 
depression  angles  but  at  moderate  ranges  (less  than  10  Km)  from  low  altitudes.  It  must  be  capable  of 
detecting  the  same  types  of  targets  that  the  surveillance  radar  does  in  order  to  reacquire  those  which 
have  moved  in  the  interim.  At  low  altitude  operation  at  very  low  depression  angles  foliage  masking 
becomes  a severe  problem  in  many  geographical  areas.  This  problem  may  be  overcome  by  using  long  wave- 
lengths (low  frequencies)  or  combinations  of  two  or  more  long  wavelengths.  Such  techniques  have  been 
proven  to  detect  military  targets  in  heavy  foliage.  This  radar  need  not  look  forward  but  can  operate  in 
the  side  looking,  synthetic  aperture,  digitally  processed  mode.  As  it  need  only  detect,  not  recognize, 
its  resolution  can  be  poor  and  it  need  not  "map"  the  terrain,  just  provide  the  direction  and  range  to 
point  the  identification  sensor  or  mark  the  line  scan  imagery.  At  low  resolution,  bandwidth  is  low  and 
cost  can  therefore  be  quite  low  compared  to  most  radars.  The  TV  or  FLIR  can  then  be  zoomed  in  on  the 
suspected  target  by  virtue  of  approach  and  by  narrowing  the  field  of  view  with  the  operator  concentrating 
on  identifying,  not  searching.  A finite  number  of  false  alarms  can  be  tolerated  as  long  as  principal 
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targets  of  Interest  are  detected  and  the  clutter  Is  not  too  great. 

The  Avionics  Laboratory  is  currently  flight  testing  a digitally  processed,  low  frequency  SAR  radar, 
called  IMFRAD  (Integrated  Multi-Frequency  Radar).  Preliminary  results  indicate  the  ability  to  detect 
tactical  targets  masked  by  camouflage  and  foliage  from  low  altitude  and  from  higher  altitude  standoff 
surveillance  ranges.  The  IMFRAD  radar  information  is  processed  on  board  the  aircraft  in  real  time  and 
does  detect  both  stationary  and  moving  tactical  sized  targets.  Because  of  the  automatic  processing  (the 
radar  detects  only  the  metal  vehicular  sized  objects)  the  IMFRAD  type  radar  can  be  used  to  search  large 
areas  and  cue  a high  resolution  sensor  for  the  final  target  classification. 


Three  Dimensional  Target  Classification.  Recent  experiments  with  a modulated,  laser  line  scan 
sensor  have  indicated  the  possibility  of  a very  discrete  automatic  target  classification  capability  using 
phase  information  to  very  accurately  discriminate  specific  military  objects  by  virtue  of  their  shape  and 
height  characteristics.  Automatic,  real-time  classification  of  specific  types  of  targets  has  been 
demonstrated  with  a high  probability  of  classification  and  a low  false  alarm  rate.  To  date,  coverage 
of  such  a sensor  has  been  restricted  to  no  more  than  20°  from  nadir  so  its  applicability  as  a cuer  for 
human  confirmation  with  a FLIR  01  -.V  in  a high  speed  vehicle,  or  for  very  wide  angle  coverage,  remains 
to  be  demonstrated.  Its  output  can  be  directly  applied  to  a down /ard  looking  sensor.  In  fact,  being  a 
line  scanner,  it  has  its  own  pictorial  output  in  the  reflectance  domain  as  well  as  a three-dimensional 
image . 

The  Air  Force  is  just  embarking  of  a program  titled  Target  Cueing  and  Classification  Sensor.  This 
program  is  designed  to  provide  USAF  with  a real  time,  airborne,  target  classification  (recognition) 
capability  for  the  low  altitude,  high  speed,  penetration  mission.  The  sensor  will  be  capable  of  obtaining 
three  dimensional  spatial  information  and  classifying  targets  based  on  shape  discrimination  to  provide  a 
high  probability  of  detection  and  a low  false  alarm  rate.  The  system  will  process  the  scene  data  in  real 
time,  <0.1  sec,  and  provide  the  user  with  the  target  name  and  location  with  respect  to  aircraft  position. 
The  system  (sensor  and  classifier)  will  fit  within  the  aircraft  sensor  bay  and  a 34  series  RPV  recce  nose. 


This  automatic  target  classif ication  capability  will  provide  usable  reconnaissance  information  in 
real  time  for  tactical  missions.  This  is  especially  valuable  against  mobile  tactical  vehicles  such  as **** 
SAMs,  AAA,  tanks,  etc.  This  system  will  have  direct  application  in  the  TAC  Quick  Strike  Reconnaissance 
and  Strike  Contnol  and  Reconnaisr ance  missions  as  well  as  in  conventional  real-time  reconnaissance.  Since 
targets  are  classified  and  located  in  real  time,  information  can  be  transmitted  to  the  user  over  a low 
bandwidth  data  lfrnk.  The  cues  will  also  alleviate  the  human  saturation  problem  experienced  with  uncued 
high  bandwidth  imagery. 


Multispectral  Cueing.  Use  of  two  or  more  sensors  or  one  sensor  operating  in  more  than  one  spectral 
band,  or  wavelength,  can  provide  information  which  can  help  to  discriminate  targets  from  their  backgrounds. 
This  is  particularly  appropriate  to  camouflaged  targets  in  which  other,  readily  sensed,  characteristics 
may  be  the  same.  A tremendous  amount  of  research  has  been  applied  to  spectral  signatures  and  discrimina- 
tion techniques.  Under  some  conditions  they  work  well.  However,  naturally  changeable  and  variable 
background  characteristics  have  compounded  the  programming  problem  and  false  alarm  rates  are  frequently 
high.  These  factors  have  inhibited  multispectral  cueing  as  a singular  technique.  If  used  in  conjunction 
with  other  cues  it  may  improve  detection  accuracy  and  reduce  overall  false  alarms. 


CONCLUSIONS 


Rapid  mobility  of  modern  military  forces  dictate  two  fundamental  requirements  for  reconnaissance 
operations:  timeliness  and  completeness.  Timely  targeting  information  is  needed  for  command  decisions 

and  reconnaissance  operations  are  incomplete  unless  information  is  accurate  and  available  during  day, 
night  and  all  weather  conditions.  Timeliness  and  completeness  are  opposing  attributes  in  that  rapid 
access  implies  a limited  quantity  of  highly  selective  data,  whereas  comprehensive  coverage  under  diverse 
conditions,  with  a high  probability  of  success,  implies  a large  amount  of  data.  An  approach  being  taken 
by  the  USAF  Avionics  Laboratory  to  reduce  this  dichotomy  is  to  employ  technological  advancements  in 
sensor  performance,  automatic  data  processing,  automatic  cueing  and  classification  sensors,  and  effective 
correlation  and  data  handling  techniques.  In  addition,  a sensor  or  processing  concept  is  not  considered 
viable  unless  it  is  affordable  and  compatible  with  operational  systems  and  concepts. 


An  example  that  illustrates  these  techniques  is  to  use  the  foliage  penetration  radar  to  cue  an 
identification  sensor.  The  radar  can  fly  at  the  low  survivable  altitude  and  cue  potential  targets.  The 
radar  can  automatically  point  a FLIR  to  the  target  area.  An  image  screener  can  then  highlight  the  targets 
for  confirmation  by  a human  decision  maker.  The  total  data  rates  are  high  but  the  human  has  to  only 
confirm  the  classification  of  the  target,  he  does  not  have  to  search.  If  this  is  a reconnaissance  mission 
then  the  image  could  be  data  linked.  If  the  transmission  were  jammed,  the  data  rate  could  be  reduced  to 
adapt  to  the  jamming  by  sending  only  the  screened  targets.  The  key  is  that  the  data  is  transformed  into 
information  as  early  in  the  cycle  as  possible  thus  allowing  maximum  flexibility.  For  the  example  of 

target  overflight  the  radar  can  direct  the  aircraft  over  the  target  area  and  a sensor  like  the  Target 

Cueing  and  Classification  Sensor  can  complete  the  reconnaissance  task  automatically  without  the  human. 

Some  of  these  concepts  may  seem  radical,  but  the  problems  are  severe  enough  that  one  must  begin  to 

consider  new  approaches  and  technologies  that  allow  real-time  data  to  be  managed  and  exploited  in  a timely 

manner . 
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DISCUSSION 


M.Stainsby 

How  is  the  figure  of  100  kHz  bandwidth  for  the  human  being  derived? 

Author’s  Reply 

This  data  rate  was  derived  from  experimentation.  I reference  a journal  article  in  my  paper.  This  article  discusses 
the  90-100  kHz  human  bandwidth  in  detail. 


I. Mir  man 

What  is  aspect  angle  sensitivity  to  determining  image  identification? 

Author’s  Reply 

Currently  all  experimentation  on  3D  imaging  has  used  downward  viewing.  Today  we  do  not  know  the  aspect  angle 
sensitivity.  We  are  initiating  research  to  experimentally  determine  the  sensitivity.  Our  goal  is  a slewable  sensor 
utilizing  this  3D  processing  technology. 
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SUMMARY 

This  paper  describes  a tactical  radar  system  whose  desigi  is  based  on  the  wide  use  of  digital  data  processing. 

These  techniques  have  replaced  analogue  and  manual  techniques  in  many  areas,  notably  those  of  communications 
and  radar  control. 

In  many  respects  there  has  been  a shift  away  from  the  traditional  approach  of  designing  a radar  and  adding  a data 
processing  sub-system.  In  the  AR3D  system  the  radar,  data  processing  and  display  and  communications  sub- 
systems have  been  designed  together,  with  the  data  processing  sub-system  providing  many  control  functions  within 
the  other  two  sub-systems. 

This  approach  has  resulted  in  the  conversions  from  analogue  to  digital  signals  on  input  (and  vice  versa  on  output) 
being  moved  closer  to  the  input  and  output  devices  themselves  (e.g.  the  radar,  displays,  air-ground-air  radio 
equipment)  making  the  overall  system  predominantly  digital  in  nature,  with  consequential  improvements  in  reliability, 
simplicity  In  manufacture  and  ease  of  deployment. 

The  paper  describes  each  main  equipment  set  within  the  system,  highlighting  those  features  and  facilities  which  are 
based  on  the  use  of  microprocessors,  special-purpose  digital  processing  logic  and  high-speed  internal  data  trans- 
mission, or  which  are  under  the  control  of  the  central  data  processing  sub-system. 

Particular  emphasis  is  placed  on  the  resilience  of  the  system  to  fault  conditions,  and  on  its  flexibility  both  in  a fault 
environment  and  when  configuring  the  system  to  meet  different  operational  requirements. 

1 . INTRODUCTION 

1.1 

The  ever-increasing  availability  of  sophisticated  aircraft  systems  has  re-emphasised  the  need  for  flexible  and 
effective  radar  systems.  Many  of  the  countries  requiring  these  systems  have  complex  territorial  environments, 
and  this  situation  demands  radar  systems  which  embody  all  the  features  normally  expected  in  strategic  systems, 
but  in  tactically  transportable  packages. 

1.2 

Plessey  Radar  has  developed  a set  of  tactical  radar  systems  modules  to  meet  this  demand  exploiting  the  full 
potentials  of  available  systems  and  hardware  technology. 

1.3 


The  Plessey  system,  incorporating  a long-range,  three-dimensional,  surveillance  radar  (the  AR3D)  with  its  own 
high-speed  signal  processing,  provides  a high  level  of  data  processing,  enabling  fast  presentation  of  essential 
information.  The  system  comprises  transportable  modules,  which  in  different  configurations  meet  a variety  of 
defence  requirements  ranging  from  forward  command  posts  handling  fifty  aircraft  tracks  to  complete  system  net- 
works containing  sector  operations  centres  handling  hundreds  of  tracks.  Stations  are  linked  by  digital  and  voice 
channels  to  produce  an  air  defence  sector  network  having  a high  degree  of  tactical  mobility,  flexibility  and  resilience. 

2.  THE  AR3D  RADAR 

2.1 

A general  view  of  the  AR3D  radar  is  shown  in  Figure  1 . The  radar  provides  long  range  coverage  for  early  warning 
(500km  range  on  15m2  target),  combining  mechanical  scanning  in  azimuth  (including  a 'fast  slew'  facility)  with 
frequency  scanning  in  elevation,  giving  heights  on  all  detected  targets  on  every  rotation  of  the  antenna. 

2.2 


The  mean  power  of  the  grldded  klystron  transmitter  is  lOOkW  but  pulse  compression  techniques  allow  the  use  of  a 
peak  power  of  1MW,  (see  para  2.5),  this  low  peak  power  giving  consequent  benefits  in  simplicity  and  reliability. 
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2.3 

Scanning  in  elevation  is  carried  out  by  applying  a swept-frequency  signal  to  the  vertical  slotted  waveguide  feed  array, 
a 30°  swing  In  elevation  being  obtained  by  a frequency  variation  of  approximately  140MHz. 

2.4 

A feature  worthy  of  particular  note  is  the  ability  to  tailor  the  coverage  of  the  radar  by  modifying  the  start  frequency 
of  the  sweep.  Using  this  technique  it  is  possible  to  tilt  the  elevation  coverage  under  computer  control  so  that  the 
high-energy  transmission  normally  reserved  for  the  low  angle  cover  can  follow  the  terrain,  thus  making  more 
efficient  use  of  the  power  of  the  radar  in  mountainous  areas  or  for  use  in  ECM  situations. 


2.5 

The  signal  received  by  the  antenna  is  amplified  and  then  split  by  means  of  filters  into  overlapping  signal  processing 
channels.  After  conversion  to  second  IF  each  channel  is  pulse  compressed  (to  0.1  us  in  the  lower  channels)  using 
acoustic  surface  wave  equalisers. 

2.6 

Each  channel  Is  then  processed  through  a video  quantiser  and  moving  window  target  detection  system,  giving  primary 
plot  statements  which  give  range,  bearing  and  elevation.  This  information  is  transferred  to  the  plot  processing 
software  in  the  computer  system. 

2.7 

Digital  MTI,  with  coverage  controlled  via  the  computer  system,  is  provided  in  the  two  lower  channels  as  standard. 

2.8 

Also  under  computer  control  are  the  first  and  second  thresholds, circuitry  providing  plot  overload  protection,  clutter 
elimination  gates  and  the  switching  on  and  off  of  the  processing  of  each  elevation  channel.  This  latter  feature 
enables  channels  subject  to  jamming  to  be  inhibited  if  necessary  In  particular  azimuth  sectors,  eliminating  possi- 
bilities of  system  overload  due  to  extremely  high  plot  rates. 

2.9 

Other  significant  facilities  Include  a Jamming  Strobe  Extractor  to  estimate  the  elevation  and  azimuth  of  jammers, 
and  the  Jamming  Influence  sensor  which  estimates  the  effective  range  of  the  radar  a jamming  environment. 

2.10 

An  on-mounted  rF  antenna,  IFF  Interrogator  and  secondary  plot  extraction  system  provide  complimentary  secondary 
radar  facilities. 

3.  DISPLAY  CONSOLES 

3.1 

Information  is  presented  at  Plessey  Series  9 Autonomous  Display  Consoles  (Figure  2),  which  are  situated  either  in 
mobile  cabins  or  remoted  up  to  500  metres  from  the  main  convoy  In  bunkers  or  other  shelters.  Each  display  console 
contains  a number  of  display  modules  providing  various  facilities,  controlled  by  a micro-computer-based  Display 
Control  Module  (DCM). 

3.2 


The  DCM  is  based  on  a DEC  LSI-11  processor  card,  with  which  are  associated  peripheral  interfaces,  a special 
bootstrap  for  loading  'down-tine'  from  the  main  processor  system,  and  memory  cards  including  a 'dual-ported' 
memory  from  which  the  Plan  Position  Indicator  (PPI)  is  refreshed  by  direct  memory  transfer.  The  effect  of  the 
special  memory  and  interfaces  Is  to  give  the  LSI-11  an  effective  power  in  the  DCM  role  equivalent  to  that  of  a 
PDP11-34  using  more  conventional  memory. 

3.3 

Refresh  of  the  PPI  is  carried  out  via  a Graphics  Module  (GM)  which  accepts  simple  commands  output  from  the 
refresh  store  and  uses  them  to  set  spot  positioning  and  write  characters  and  vectors.  Each  character  is  constructed 
from  a number  of  short  straight  lines  or  'limbs',  the  average  number  for  a typical  character  being  around  23,  giving 
characters  of  very  high  quality.  Average  writing  time  for  a character  is  around  3^is,  and  for  vectors  64  us  for  a 
screen  diameter.  These  writing  times  enable  complex  display  presentations  to  be' provided,  particularly  useful 
where  map  information  is  concerned.  Uniformity  of  brightness  and  dim  : bright  ratios  are  maintained  by  the  use 
of  constant-rate  character  and  vector  generation,  and  the  digital  display  file  specification  means  that  large  characters 
and  picture  expansion  can  be  obtained  without  the  degradation  associated  with  analogue  expansion  techniques. 
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3.4 

The  Radar  Module  (RM)  converts  radar  video  signals  for  display  as  an  'overlay'  to  the  graphics  information.  Digital 
techniques  are  again  widely  used,  with  radar  range  and  radar  centre  offset  being  controlled  by  the  software  within  the 
DCM. 

3.5 

The  Indicator  Module  (IM)  which  contains  the  CRT  offers  a very  high  writing  speed  and  good  linearity.  The  deflection 
coil  driver  uses  a high-efficiency  printed  coil  giving  a fast  spot  settling  time  (around  7ps  for  a screen  radius)  and  a 
positional  accuracy  of  1%.  A contrast  enhancement  screen  reduces  specular  and  diffuse  reflections  considerably, 
giving  a high  contrast  picture  even  in  normal  room  lighting  conditions. 

3.6 

Tabular  information  is  displayed  on  two  Electronic  Data  Displays  (EDDs)  (Figure  3)  which  use  512  x 512  line  gas 
discharge  panels  (commonly  known  as  'plasma  panels')  as  their  display  media.  The  main  advantages  of  this  type 
of  display  over  a conventional  CRT  are  the  self-refreshing  nature  of  the  panel  display,  the  screen  'flatness'  and 
the  considerably  smaller  depth  required.  This  latter  factor  is  particularly  important  in  a mobile  system  where 
space  is  at  a premium. 

3.7 

Each  EDD  Is  overlayed  by  a Touch  Input  Device  (TID)  formed  from  an  array  of  intersecting  infra-red  beams.  The 
TID  enables  each  EDD  to  be  used  as  a programmable  keyboard,  and  this  capability  is  fully  exploited  in  the  operational 
facilities  of  the  system. 

3.8 

The  console  is  also  equipped  with  a Rolling  Ball  Unit  for  the  input  of  positional  information  and  a small  alphanumeric 
keyboard  for  use  in  data  entry  (e.g.  for  flight  plans),  together  with  communications  control  panels  appropriate  to  the 
particular  system  requirement. 

3.9 

Information  of  a more  static  nature  (e.g.  detailed  ground  maps,  maintenance  information)  can  be  displayed  on  an 
Ancillary  Information  Projector  (AIP)  mounted  in  the  top  of  each  console.  The  AIP  uses  35mm  roll  film,  each  roll 
providing  up  to  1000  individual  frames,  with  electronic  frame  counting  being  provided. 

4.  COMPUTER  SYSTEM 

4.1 

The  main  processing  system  contained  in  each  of  the  modules  with  data  processing  facilities  (i.e.  the  radar  pro- 
cessing and  control  cabin,  display  cabin  and  communications  control  cabin)  is  based  on  the  PM  1150  ruggedised 
processor  manufactured  by  Plessey  in  California.  The  main  element  of  this  processor  is  a PDP11-34  processor 
card  supplied  by  Digital  Equipment.  The  PDP11  was  chosen  as  the  basis  for  this  equipment  for  many  reasons,  a 
major  one  being  the  wide  availability  of  peripherals,  interfaces  and  software,  both  from  DEC  itself  and  from  many 
other  suppliers. 

4.2 

A ruggedised  mounting  box  and  power  supply  are  used,  with  special  arrangements  for  handling  signal  and  power 
cables,  and  other  than  the  processor  cards  and  certain  memory  elements  the  rest  of  the  processor  configuration 
is  designed  and  manufactured  by  Plessey.  Peripherals  are  also  specialised  with  a rack-mounted  control  terminal, 
ruggedised  disc  drives  (Vermont  Research  Corporation)  and  a floppy  disc  system. 

4.3 

The  dual  processing  system  (Figure  4)  in  a typical  display  cabin,  supporting  six  display  consoles,  provides  a total 
of  1 76K  words  of  core  memory  and  100M  bytes  of  disc  storage.  Each  radar  processing  and  control  cabin  and 
communications  control  cabin  is  similarly  equipped  with  computer  equipment. 

4.4 

When  the  cabins  are  connected  together,  a complete  computer  network,  containing  typically  six  to  fourteen  PM  1150 
processors,  is  set  up  using  high-speed  digital  links  to  interconnect  the  processors.  Data  paths  are  duplicated, 
providing  for  automatic  re-routing  of  data  in  the  event  of  failure  of  a primary  path.  Figure  5 shows  a typical 
computer  network. 
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Interconnection  between  the  computer  systems  at  different  stations  Is  provided  by  a communications  network  using 
duplicated  2.4K  bits/second  data  links.  The  software  provides  for  routing  of  messages  to  particular  consoles, 
operators  or  stations,  including  multiple  destinations. 

5.  DATA  PROCESSING  FACILITIES 


5.1 


Distributed  digital  data  processing  has  a greater  Influence  on  system  facilities  than  has  previously  been  the  norm. 
From  the  radar  through  to  the  communications  system,  digital  control  Is  used  In  almost  every  area. 


5.2 


The  high-speed  primary  radar  video  processing  logic,  itself  basically  a special-purpose  digital  processor,  is  set 
up  and  controlled  In  real  time  from  the  main  computer  system.  In  this  way  many  of  the  radar  facilities  such  as 
electronic  tilt,  the  digital  MTI  system  and  various  thresholds  in  the  plot  extractor  can  be  set  up  either  under  op- 
erator control  from  any  display  console  or  automatically  under  software  control,  to  give  quick  response  to  situations 
such  as  ECM  and  other  environmental  factors. 


5.3 


Once  the  primary  and  secondary  radar  information  is  output  by  the  plot  extractors,  it  Is  used  to  create  tracks  by 
automatic  Initiation.  The  software  In  the  main  processing  system  Is  designed  to  provide  computer  assistance  to 
operators  by  performing  routine  tasks  and  by  giving  quick  access  to  a large  amount  of  Information.  The  emphasis 
Is  on  computer  assistance  rather  than  automation;  the  system  provides  a flexible  and  comprehensive  tool  for  the 
operator  to  use,  rather  than  trying  to  do  his  job  for  him.  Computer  assistance  is  provided  to  a wide  range  of 
operational  tasks,  including  track  recognition,  evaluation  of  threats,  selection  of  the  appropriate  reaction,  fighter 
interceptions,  strike  missions  and  recoveries,  flight  plan  processing  and  association,  and  many  others.  Integral 
simulation  facilities  are  provided  for  operator  training  and  for  facility  evaluation. 


5.4 


The  facilities  provided  to  the  display  consoles  are  extremely  flexible  and  designed  for  simplicity  In  use.  Information 
is  provided  in  a variety  of  forms  on  both  the  labelled  radar  or  plan  displays  and  the  electronic  data  displays.  Most 
information  may  be  displayed  on  either  type  of  display  at  operator  request. 


5.5 


Of  particular  note  is  the  use  of  general-purpose  console  equipment,  with  functions  being  assigned  under  software 
control.  This  allows  an  operator  to  perform  his  duty  at  any  console,  and  to  move  to  a spare  console  if  equipment 
at  his  current  console  location  fails. 


5.6 


Hlgh-resolutlon  digital  maps  are  displayed  on  the  plan  displays,  with  an  increasing  level  of  detail  being  shown  as 
the  display  range  Is  expanded  under  software  control.  Display  parameters  may  be  changed  from  metric  to  imperial 
units  by  operator  selection,  and  the  plan  display  may  be  centred  on  an  area  of  Interest  either  by  operator  selection 
or  directly  under  software  control. 

5.7 

The  Touch  Input  Devices  (TIDs)  which  overlay  the  EDDs  provide  a flexible  keyboard  facility.  Most  data  can  be 
amended  directly  by  touching  the  appropriate  item  In  a tote  display  and  then  Inputting  the  new  value;  conventional 
input  sequences  are  used  only  for  the  longer  multiple  value  Inputs,  and  In  these  cases  only  the  Inputs  which  are 
legal  at  any  one  time  are  presented  to  an  operator  for  selection,  thus  significantly  reducing  operator  errors. 


5.8 


Point-to-point  communications  and  Intercommunication  facilities  are  also  under  software  control;  this  is  described 
in  more  detail  when  the  overall  communications  facilities  are  considered,  In  Section  6. 


5.9 


Comprehensive  data  recording  Is  provided,  with  variable  speed  replay  and  analysis.  Logging  of  both  technical  and 
operational  parameters  enables  the  performance  both  of  the  station  and  the  operational  personnel  to  be  monitored. 

5.10 

The  data  recording  facilities  are  linked  to  a voice  recorder  which  records  the  communications  activity  at  the  consoles. 
On  replay,  voice  and  data  recordings  can  be  synchronised  to  provide  a comprehensive  real-time  representation  of  the 
recorded  situation. 
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5.11 

The  software  Is  highly  modular  and  uses  the  total  computer  complex  as  a virtual  machine.  Many  software  elements 
are  duplicated  In  different  processors  to  provide  reconfiguration  capability  under  failure  conditions,  and  the  data 
base  Is  also  duplicated  across  the  station.  Software  is  written  In  a high-level  language,  RTL/2,  and  Is  structured 
and  documented  using  structured  plain  code  (SPC),  a technique  designed  to  give  clear  documentation  minimising  the 
need  to  use  flow  diagrams  which  are  expensive  to  produce  and  maintain. 

6.  COMMUNICATIONS 

6.1 


The  point-to-point  and  intercom,  facilities,  both  within  and  between  stations,  are  provided  by  a special  type  of 
processor  - controlled  telephone  exchange.  This  exchange,  called  the  voice  switch  system,  is  under  direct  control 
of  the  main  processor  system,  thus  making  its  facilities  available  to  users  via  the  display  and  Input  devices  In  the 
consoles.  In  particular,  calls  are  made  using  the  TED  and  EDD  to  make  selections  from  subsets  of  the  overall 
directory.  When  an  operator  'signs  on',  the  system  automatically  gives  him  fast  access  call  facilities  to  other 
operators  associated  with  his  job.  The  system  directs  calls  to  subscribers  either  by  name  or  by  job  title,  wherever 
they  are  located  In  the  sector,  and  provides  facilities  such  as  conferencing,  multiple  levels  of  priority  and  call-back 
listings.  Calls  made  to  job  titles  who  are  not  currently  'signed  on'  are  automatically  routed  to  the  appropriate 
Immediate  superior  of  the  person  called. 

6.2 

The  voice  switch  system  also  handles  calls  to  external  agencies  such  as  airfields,  missile  sites  or  higher  echelons, 
and  Interfaces  with  field  telephones  and  field  exchanges.  Figure  6 is  a diagram  of  a typical  voice  switch  system. 

6.3 

The  air-ground-air  communications  system  makes  extensive  use  of  digital  techniques,  both  tc  reduce  cabling  and 
to  provide  flexible  operational  facilities.  The  frequency  synthesisers  of  the  VHF/UHF  transmitters  and  receivers 
are  remotely  controlled  from  the  users'  consoles  via  a microprocessor-based  multiplexing  system.  In  addition, 
the  relationship  between  channel  number  and  frequency  is  set  up  under  processor  control  and  can  be  displayed  as 
one  of  the  Information  totes  at  any  system  console. 

6.4 


As  a standby  point-to-point  system,  and  to  provide  access  into  the  public  telephone  network,  a microprocessor- 
based  PAX  is  provided,  giving  a comprehensive  set  of  facilities. 

6.5 

At  the  lowest  level  of  communication,  each  console  and  system  module  (including  power  generators)  is  fitted  with 
a technical  Intercom,  system  using  self-powered  headsets  which  are  carried  by  technicians.  This  system  aids 
in  setting  up  a station  or  in  other  situations  where  prime  power  is  unavailable  for  the  other  communications  facilities. 

6.6 

A teleprinter  network  is  provided  to  link  stations  and  external  agencies  such  as  airfields,  the  meteorological  service, 
civil  flight  plan  and  service  and  so  on. 

6.7 

Communications  channels  between  cabins,  stations  and  to  external  agencies  are  carried  by  a variety  of  types  of 
communications  bearer.  Between  cabins  within  a station,  and  to  remotely  deployed  consoles,  balanced  line  trans- 
mission of  both  data  and  voice  uses  mobile  point-to-point  equipment  (UHF,  troposcatter  etc.)  or  (in  more  static 
environments)  private  or  leased  lines. 

7.  CONFIGURATIONS 

7.1 

A minimum  station  configuration  comprises  four  mobile  units  - the  antenna,  the  transmitter  cabin,  the  radar- 
processing and  control  cabin  and  the  mobile  power  supply.  This  can  be  enhanced  by  display  and  communications 
cabins  as  required  to  meet  the  system  application.  A station  can  be  increased  in  capacity  by  adding  more  cabin 
modules  to  handle  larger  numbers  of  tracks  and  provide  more  display  consoles,  the  only  practical  constraint  being 
that  of  response  time  across  the  extended  station  configuration. 

7.2 


The  AR3D  antenna  unit  (Figure  7)  consists  of  a compact,  circularly  polarised  linear  feed  array  positioned  at  the 
focus  of  a simple  parabolic  cylinder  reflector.  The  reflector  is  of  lightweight  design  and  folds  easily,  being 
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raised  and  lowered  hydraulically,  allowing  for  rapid  and  easy  deployment. 


7.3 


The  Transmitter  Cabin  (Figure  8)  contains  low-power  swept  pulse  generation  equipment,  a coherent  high-power 
S-band  transmitter  and  a wideband  receiver  amplifier. 


7.4 


The  Processing  and  Control  Cabin  (Figure  9)  contains  equipment  necessary  for  receiver  signal  processing,  primary 
plot  and  height  extraction,  secondary  plot  extraction,  digital  MTI,  radar  monitoring  and  control,  a dual  processor 
system  and  up  to  five  labelled  radar  display  consoles  with  associated  communications  facilities.  Two  remote  trans- 
portable consoles  may  also  be  connected  to  this  cabin  module. 


7.5 


The  Display  Cabin  (Figure  10)  contains  a dual  processor  system  and  six  labelled  plan/radar  display  consoles  with 
associated  communications  facilities. 


7.6 


The  A/G/A  and  Communications  Control  Cabin  contains  a variety  of  equipment  depending  on  station  role  and  user 
requirements.  A typical  cabin  is  shown  in  Figure  11.  It  is  fitted  with  UHF/VHF/HF  air-ground  air  communications 
equipment,  the  main  communications  voice  switch,  the  PAX,  voice  recorder  teleprinter  and  equipment  and  dual  pro- 
cessor system  handling  point-to-point  data  communications  via  modems. 


7.7 

A point-to-point  Communications  Bearers  Cabin,  when  required,  contains  the  microwave  or  UHF  multi-channel 
point-to-point  terminals,  Troposcatter  or  other  terminals  may  also  be  used. 


7.8 


The  Workshop  Cabin  provides  a self-contained  workshop  capability  which  is  Immediately  available  in  the  field 
providing  each  station  with  a limited  but  autonomous  repair  and  maintenance  facility. 


7.9 


A typical  Reporting  Post  (Figure  12)  would  use  the  minimum  station  configuration  providing  automatic  Initiation  and 
tracking  of  60  to  100  tracks,  with  limited  communication  facilities. 

7.10 

Adding  a communications  cabin  provides  full  air-ground-air  communications  and  enables  the  capabilities  of  the  data 
processing  system  to  be  exploited,  giving  control  facilities  in  the  form  of  6 - 12  computer-assisted  interceptions  or 
strike  missions. 

7.11 

The  capacity  and  facilities  of  the  station  may  then  be  improved  by  adding  display  cabins,  and  stations  such  as  the 
Sector  Operations  Centre  (Figure  13)  can  be  configured. 

7.12 

These  various  types  of  station  may  also  be  integrated  into  complete  systems  (Figure  14),  providing  overall  air 
defence  co-ordination  facilities  over  one  or  more  operational  sectors. 

8.  MOBILITY  AND  DEPLOYMENT 


8.1 


The  system  modules  are  designed  to  be  transportable  by  road,  rail  and  air,  Road  transportation  is  by  four-wheeled 
trailer  or  by  semi-trailer  and  the  modules  are  designed  within  normal  international  road  and  rail  transportation 
envelopes.  Air  transportation  is  by  C130  or  C160  aircraft.  Figure  15  shows  a Processing  and  Control  Cabin  with 
5 displays,  mounted  on  a serai-trailer. 


8.2 


Multl-trans  running  gear,  a type  of  low-speed  mobiliser,  Is  used  to  assist  in  moving  the  modules  on  and  off  the 
trailer,  rail  vehicle  or  aircraft.  This  equipment  is  adjustable  in  height  to  match  a wide  variety  of  loading  platforms. 
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9.  AVAILABILITY 

9.1 

The  system  Is  designed  to  provide  an  extremely  high  level  of  availability,  by  minimising  the  effect  of  individual 
equipment  failure  and  by  providing  comprehensive  built-in  test  facilities. 


9.2 


The  radar  Built-In  Test  Equipment  (BITE)  allows  monitoring  of  parameters  and  waveforms  within  the  radar  processing 
sub-system  to  Isolate  faults  down  to  PCB  level.  Digital  and  analogue  highways  connect  all  major  sub-units  within  the 
radar  to  a BITE  operating  station  positioned  at  the  Technical  Monitor  Console  (Figure  9)  and  the  status  of  major 
equipments,  determined  on  a GO/NOGO  basis,  is  continuously  displayed  on  a mimic  diagram. 


9.3 


* 


The  computer  equipment  is  duplicated  within  each  cabin,  with  facilities  such  as  the  display  consoles  and  radar  input 
Interfaces  being  accessible  to  either  of  the  processors.  In  the  case  of  the  communications  control  cabin,  a hot 
standby  processor  is  provided  within  the  computer  system.  The  overall  computer  network  is  able  to  accept  failures 
of  single  and  multiple  computers  while  continuing  to  provide  useful  operational  facilities. 


9.4 


l 


Defensive  programming  techniques  are  widely  employed  within  the  software  making  it  robust  even  in  situations  of 
hardware  malfunction.  All  hardware  Inputs  are  checked  for  validity,  and  data  packets  transferred  between  software 
tasks  are  re-validated  by  the  receiving  task. 


9.5 


The  overall  network  of  computers,  peripherals  and  displays  is  routined  by  the  software  to  detect  hardware  mal- 
functions. A comprehensive  software  diagnostic  package  is  also  provided  to  assist  in  fault-finding  and  equipment 
repair. 


9.6 


The  use  of  digital  techniques  reduces  dramatically  the  amount  of  cabling  required,  particularly  In  the  communications 
sub-system,  and  allows  alternative  control  paths  to  be  utilised  in  the  event  of  failure  of  the  normal  path. 


9.7 


A comprehensive  alarm- monitoring  facility  is  provided  with  an  equipment  alarm  panel  placed  In  a prominent  position 
In  each  cabin.  The  alarms  from  the  power  generators  and  unmanned  Transmitter  Cabin  are  also  routed  to  these 
panels. 


9.8 


A Workshop  Cabin  can  be  provided  with  each  station,  allowing  field  repair  to  be  carried  out.  A particular  feature  of 
the  workshop  cabin  is  the  display  console  test  harness  which  has  access  to  the  videos  and  timing  signals  from  the  live 
system,  allowing  display  modules  to  be  tested  using  live  data  and  thus  minimising  the  use  of  special  test  equipment. 

10.  CONCLUSION 


10.1 


This  paper  has  described  a flexible  and  sophisticated  tactical  radar  system  Incorporating  many  features  not  usually 
associated  with  tactical  systems.  The  syftem  is  characterised  by  an  extremely  wide  use  of  digital  data  processing, 
giving  major  Improvements  In  availability,  ease  of  deployment  and  level  of  facilities.  The  distributed  computer 
system  enables  a wide  variety  of  operational  requirements  to  be  met  using  a standard  range  of  equipment  modules. 
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Photograph  of  typical  series  9 display  console 
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Fig.3  Photograph  of  EDD  assembly 


Fig.6  Diagram  of  voice  switch  system 
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Fig.9  Schematic  of  typical  processing  and  control  cabin 
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Fig.  1 0 Schematic  of  typical  display  cabin 


Fig.  1 1 Schematic  of  typical  A/G/A  and  communications  control  cabin 


CAPACITIES 


Operator  Consoles  — S ( * 2 Remote) 
Track  Capacity  — 120 


Fig.  1 2 Diagram  of  reporting  post 


CAPACITIES:  Operator  Consoles  — 29 

Intercept  Capacity  — 36  Close  Control 

Track  Capacity  — 300 

Other  Facilities  — Multi-radar  Netting,  Sector  Control,  Threat  Evaluation. 
Weapon  Suggestion,  Flight  Plan  Processing.  SAM/LAA  Control. 

Strike.  Simulation 


Fig.  1 3 Diagram  of  sector  operations  centre 


Fig.  1 4 Typical  system  configuration 


DISCUSSION 


H.B.Driessen 

You  mentioned  in  your  oral  presentation  an  upper  limit  for  the  density  where  you  attempt  automatic  initiation. 
Could  you  quantify  this  upper  density? 

author’s  Reply 

There  will  be  a clutter  density  above  which  automatic  initiation  will  not  be  attempted  due  to  the  large  number  of 
possible  tracks  that  could  be  initiated.  This  density  will  depend  on  the  scan  time  of  the  radar,  the  maximum 
velocity  tracks  being  initiated  and  the  total  number  of  tentative  (or  acquisition)  trails  that  the  system  can  cope  with. 


G.  Van  Keuk 

When  you  net  radars  on  the  data  processing  level  you  sometimes  have  the  problem  that  the  sensors  are  not  ideally 
aligned.  Have  you  studied  the  sensitivity  of  the  various  strategies  against  misalignment  and  inaccurate  positioning. 

Author’s  Reply 

In  a multiradar  tracking  situation,  the  two  greatest  problems  are  probably  lack  of  any  height  information  and  the 
misalignment  ot  radars.  Both  these  situations  will  lead  to  bias  errors.  However  il  these  bias  errors  remain  reasonably 
constant  over  a sufficiently  long  period  of  time  these  biases  may  be  estimated  algorithmically  by  selecting  straight- 
line  sections  of  tracks,  either  from  aircraft  flown  for  that  purpose  or  from  targets  of  opportunity.  It  also  appears 
that  these  biases  will  vary  range  and  azimuth  of  the  various  radars  and  therefore  the  most  practical  solution  will  be 
to  average  the  biases  from  several  straight-line  tracks.  A second  problem  appears  to  be  the  time  dependence  of  the 
biases  so  that  their  estimation  will  have  to  be  repeated  periodically.  These  algorithms  can  be  run  off  line  (not  in 
real  time)  and  can  therefore  be  quite  complex.  We  have  investigated  a linear  least  squares  technique  which  involves 
a relatively  large  matrix  inversion  that  has  resulted  in  satisfactory  bias  estimations. 


J.B.Tasche 

Can  you  give  information  on  the  extra  core  space  required  by  your  using  RTL-2  instead  of  MACRO-1 1 and  also 
what  is  the  extra  program  run-time? 

Author’s  Reply 

We  have  no  statistically  significant  data  on  the  efficiencies,  but  it  would  appear  that  between  30%  and  60%  extra 
memory  might  be  needed.  However,  we  find  that  very  good  programmers  can  produce  RTL-2  which  is  as  efficient 
as  their  good  assembler.  We  have  also  found  that  a poor  programmer  often  produces  RTL-2  which  is  more  efficient 
than  his  assembler.  On  run-time,  we  are  not  really  able  to  distinguish  between  the  operating  system  overhead  and 
the  language  overhead  since  this  is  our  first  use  of  both  of  these. 

J.B.Tasche 

In  the  UK  there  is  a well  established  standardisation  for  the  use  of  Coral  66  for  MOD  projects.  There  are  in  existence 
a few  Coral  66  compilers  for  PDP-1 1 . Why  not  RTL-2  selected  instead  of  Coral  66? 

Author’s  Reply 

Two  factors  are  relevant  to  this  particular  choice.  At  the  time  the  project  was  begun,  the  PDP-1 1 Coral  66  compilers 
were  very  unreliable  (we  benchmarked  three  compilers).  We  actually  chose  an  operating  system  (MTS)  before  the 
language.  Coral  66  was  not  supported  under  MTS,  a very  mature  and  reliable  RTL-2  compiler  was  available  so  we 
used  it.  The  operating  systems  which  did  support  Coral  66  were  not  truly  real-time  and  we  could  not  accept  the 
overhead. 


1 A.  Clear  waters 

Concerning  the  security  of  your  system,  two  points:  Can  you  prevent  unauthorised  user  from  getting  into  the 
system?  The  common  displays  allow  any  format  on  any  display.  Are  there  any  methods  for  controlling  a low-level 
user  from  calling  up  and  using  supervisory  formats?  In  other  words,  does  the  system  enforce,  through  its  formats, 
the  hierarchal  nature  of  a military  system? 

Author’s  Reply 

There  are  certain  limited  features  which  prevent  unauthorised  users  accessing  the  system,  particularly  from  remote 
terminals.  Formats  are  role-oriented  in  the  way  you  describe.  Many  formats  can  only  be  accessed  via  a supervisory 
role. 
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SUMMARY 

This  paper  discusses  a method  for  improving  the  man-machine  interface  in  civil  and  military  data  automation 
capabilities.  The  method  combines  existing  hardware  technology  with  innovative  software  features  to  pro- 
vide an  interactive  capability  responsive  to  the  system  user.  Integral  to  the  concept  is  the  use  of  a 
touch  entry  device  and  a tabular  display  for  message  composition  and  entry.  One  or  more  tabular  displays 
are  used  for  the  presentation  of  data  forced  to  the  position  or  requested  by  the  user.  Support  software  is 
discussed  including  the  use  of  implied  logic  designed  to  facilitate  the  message  entry  process,  branching 
logic  to  guide  or  prompt  the  user  in  formatting  messages  for  entry  to  the  system,  and  display  logic  respon- 
sive to  the  needs  of  the  position. 

Techniques  for  application  of  this  technology  to  a real-time  system  like  Air  Traffic  Control  are  described 
in  detail.  Potential  application  to  other  types  of  systems  is  identified.  This  paper  concludes  with  a 
summary  of  benefits  expected  to  be  attainable  through  implementation  of  various  aspects  of  the  described 
method. 


INTRODUCTION 

In  the  past  decade,  tremendous  progress  has  been  achieved  in  hardware  and  software  technology  to  meet  civil 
and  military  data  automation  requirements.  However,  the  ability  of  a system  user  to  efficiently  and  expe- 
ditiously manipulate  and  utilize  information  derived  from  this  technology  significantly  depends  on  the  man- 
machine  interface  established  for  the  system.  In  general,  there  is  a continuing  need  to  improve  the  tech- 
nology of  this  interface  in  order  to  achieve  benefits  such  as; 

•Simplifying  the  message/command/data  entry  process: 

•Reducing  the  incidence  of  input  errors  affecting  both  the  stored  data  base  and  the  resulting 
processing  and  display  of  essential  information; 

•Reducing  the  overall  man-machine  response  times,  not  just  the  response  times  associated  with 
internal  computer  processing; 

•Tailoring  of  information  displayed  at  an  operating  position  to  meet  the  needs  of  that  position: 
•On-line  assistance  in  tactical  and  strategic  planning;  and, 

•Providing  a dynamic  capability  to  assist  in  the  training  of  system  operators  and  users,  thereby 
shortening  the  training  cycle. 

The  purpose  of  this  paper  is  to  present  a concept  for  improving  the  man-machine  interface.  This  concept 
represents  a merging  of  existing  hardware  technology  with  innovative  software  features  to  produce  a more 
viable  symbiotic  environment,  which  is  most  useful  in  assisting  or  prompting  the  user  in  entering  frequently 
as  well  as  infrequently  used  messages  into  a system.  An  example  of  the  applicability  of  this  concept  to  a 
system  like  Air  Traffic  Control  is  presented  as  a way  of  illustrating  the  potential  of  this  approach  to 
improving  the  man-machine  interface. 

The  concept  was  developed  under  the  auspices  of  the  Federal  Aviation  Administration  (FAA) , Systems  Research 
and  Development  Service,  as  part  of  an  overall  plan  for  sector  position  design  improvements.  The  intent  of 
the  plan  is  to  provide  additional  automation  at  sector  control  positions  in  order  to  enhance  the  operation 
of  the  Air  Traffic  Control  System  and  to  increase  productivity  within  controlled  volumes  of  airspace. 

An  experimental  subsystem  incorporating  the  interactive  capabilities  described  in  this  paper  is  currently 
under  development  as  the  first  step  to  providing  the  additional  automation.  This  subsystem,  known  as  ETABS 
(Electronic  Tabular  Display  Subsystem}  is  designed  to  replace  flight  progress  strips  and  to  simplify  con- 
troller message  entry  in  the  Air  Route  Traffic  Control  Centers  (ARTCCs) . ETABS  is  expected  to  reduce  the 
current  manual  and  relatively  intensive  workload  associated  with  flight  data  bookkeeping  and  updating 
functions . 

The  basic  design  of  this  subsystem  has  been  demonstrated  at  the  MITRE  Corporation,  Metrek  Division,  in 
McLean,  Virginia.  This  design  served  as  the  basis  for  generation  of  the  specifications  for  an  Engineering 
Model  to  be  installed  at  the  FAA  National  Aviation  Facility  Experimental  Center  in  Atlantic  City,  New  Jersey. 
The  subsystem  will  be  evaluated  in  a simulated  operational  environment  to  assure  that  the  design  meets  the 
operational  requirements  of  the  sector  control  team.  The  results  of  this  evaluation  is  planned  to  be  used 
for  development  of  the  production  specifications  for  an  operational  system. 

Potential  application  of  the  described  concepts  to  other  automation  capabilities  is  discussed.  This  paper 
identifies  those  basic  functions  within  generic  systems  most  amenable  to  these  design  concepts.  The  paper 
concludes  with  a summary  of  the  potential  benefits  expected  to  be  achieved  by  improving  the  man-machine 
interface. 
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MAN-MACHINE  INTERFACE  PROBLEMS 

The  complexity  of  the  message  entry  process  is  a fundamental  problem  with  the  man-machine  interface.  This 
can  be  attributed  to  the  input  devices  used  to  specify  data  for  entry  to  a system  and  to  the  software 
designed  to  support  message  composition.  Most  electro-mechanical  input  devices,  such  as  keyboards,  keypacks 
and  switches,  are  cumbersome  to  use  and  contribute  to  a message  entry  process  which  is  time-consuming  and 
error  prone.  A variety  of  software  command  languages,  text  editors,  etc.  have  been  designed  to  accommodate 
particular  devices  already  selected  for  a system.  However,  more  needs  to  be  done  to  facilitate  message 
composition  by  guiding  or  prompting  the  user  through  each  sequential  step  in  the  message  entry  process.  In 
addition,  software  tends  to  expand  to  meet  increased  operational  requirements,  thereby  adding  to  the  com- 
plexity of  message  entrv. 

This  problem  has  been  recognized  over  the  years.  In  1971,  Culhane  pointed  out  that  ten  input  devices  are 
used  at  the  radar-controller  position  in  the  U.S.  Air  Route  Traffic  Control  Centers  (ARTCCs) . He  stated 
that,  "while  each  individual  input  action  is  not  necessarily  difficult  for  the  controller  to  perform,  input 
actions  are  awkward,  complex  and  cumbersome".  In  1972,  Parsons  reported  on  some  earlier  studies  of  illegal 
(computer  incorrect)  switch  actions  taken  during  SACP  Air  Defense  exercises.  Those  studies  found  12.5%  of 
all  switch  actions  to  be  illegal  and  that,  "the  number  of  illegal  actions  rose  as  the  load  increased  on  an 
individual  operator".  More  recently,  a study  performed  by  Amato  in  1977  showed  that  input  error  rates  at 
supporting  radar  positions  in  two  ARTCCs  approached  25%.  This  confirmed  previous  studies  indicating  the 
same  error  rate  at  other  facilities. 

The  presentation  of  information  is  another  problem  that  needs  to  be  addressed  if  the  man-machine  interface 
is  to  be  improved.  One  aspect  of  this  problem  is  that  a mismatch  (Hopkins,  V.D...1975)  occurs  in  the  dis- 
play of  information  in  relation  to  the  user's  comprehension  of  that  information.  Hopkins  rightly  claims 
that,  "a  discrepancy  between  the  information  provided  and  the  information  used  occurs  in  modem  systems 
which  contain  more  information  than  can  be  assimilated  or  displayed".  There  is  little  operator  control  over 
the  quantity  and  the  selectivity  of  information  presented  or  displayed  at  most  operating  positions. 

Response  time  is  another  area  of  concern  and  should  include  the  time  for  system  detection  of  input  errors 
and  the  time  required  by  the  operator  to  correct  these  errors.  It  is  often  stated  that,  "the  response  time 
is  the  elapsed  time,  measured  in  seconds,  between  the  completion  of  a user  command  and  the  receipt  of  a user 
reply"  (Gardella,  R.S. . . . 1976) . In  actuality,  the  total  response  time,  from  initiation  of  an  input  message 
and  then  entry,  to  receipt  of  an  accept  reply  should  be  used  as  a measure  of  responsiveness.  In  most  systems, 
this  total  time  can  be  critical. 

One  additional  problem  with  current  interface  designs  is  worth  mentioning.  This  is  the  training  required  to 
operate  and  use  a system.  Lengthy  training  cycles  are  the  vogue  in  many  systems  with  a resultant  cost  in 
time  and  personnel.  As  Locher  (Locher,  J.P....1969)  stated,  "If  it  takes  a lot  of  training  and  operating 
time  to  develop  this  capability  (of  using  the  interface),  there  are  serious  man-machine  problems  that  should 
be  promptly  resolved". 

Perhaps  the  overriding  problem  with  the  man-machine  interface  is  the  tendency  of  system  designers  to  design 
systems  so  that  the  interface  is  computer  oriented  rather  than  user  oriented.  In  most  cases,  resources  are 
heavily  committed  to  developing  the  mechanics  of  system  operation,  such  as  the  architecture  of  the  software, 
the  communication  facilities,  and  the  data  base  storage  techniques.  Too  little  attention  is  committed  to  an 
interface  design  to  facilitate  the  use  of  the  system.  This  needs  to  be  changed  if  the  full  capabilities  of 
data  automation  are  to  be  realized  through  a synergism  of  hardware,  software  and  man-machine  interface  tech- 
nology . 
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INTERACTIVE  DESIGN 


Most  of  the  problems  described  earlier  can  be  alleviated  by  upgrading  the  interface  capabilities  at  the 
operating  position  itself.  This  can  be  done  by  providing  improved  message  entry  and  display  devices  and  by 
supporting  these  devices  with  local  data  processing.  The  basic  technology  for  doing  this  exists  today  in 
the  form  of  touch  entry  devices  operating  in  conjunction  with  tabular  displays,  and  the  use  of  displays  for 
data  presentation.  This  approach  is  not  new.  In  fact,  some  of  the  techniques  described  in  this  paper  are 
based  on  consideration  of  the  work  performed  in  the  United  Kingdom  (CAA  Paper  77020 ....  1976)  and  at  EURO- 
CONTROL . 

Touch  entry  is  currently  being  used  in  a number  of  other  systems  and  tabular  displays  are  becoming  more 
popular  for  the  output  of  information  from  a central  computer  system.  However,  it  is  the  combination  of 
these  devices  plus  localized  data  processing  and  special  software  features  which  shows  the  greatest  promise 
of  improving  the  interface.  This  combination  can  be  used  to  tailor  the  interface  to  meet  the  needs  of  the 
position  and  beyond  this,  the  needs  of  the  individual  operating  the  position. 

TOUCH  ENTRY 

A touch  entry  device  overlaying  or  operating  with  a tabular  display  simplifies  tbe  man-machine  interface. 
The  selection  of  displayed  data  becomes  a natural  extension  of  the  thinking  process.  The  user  can  quickly 
and  easily  indicate  to  the  system  the  selected  data  by  merely  touching  a displayed  field  or  item.  This 
technique  can  be  used  for  message  composition  and  entry,  to  provide  a rapid  means  of  communicating  with  the 
host  computer  system,  and  to  manage  the  display  of  information  at  the  user  position. 

Two  of  the  touch  entry  methods  in  use  today  are: 

•Light  beam  overlay  consisting  of  light  emitting  diodes  (LEDS)  in  a phototransister  array  creating 
an  X-Y  grid  over  the  surface  of  a display. 


•Pressure  sensitive  devices  imbedded  within  the  surface  of  a display  - e.g.,  wires,  acoustical 
"pads",  thin  tubes. 
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The  LED  method  requires  that  an  X and  a Y beam  be  broken  to  enable  the  device  to  determine  the  location  of 
the  touch  point.  When  a finger  breaks  the  grid,  light  beams  are  interrupted.  These  interruptions  are 
sensed  by  the  associated  transmit-receive  pair.  The  address  of  the  interruption  point  is  then  determined 
by  the  touch  panel  electronics  and  transmitted  to  the  computer.  It  is  not  necessary  to  touch  the  display 
surface.  The  pressure  sensitive  method  requires  physical  contact  with  the  displayed  data  in  order  to  select 
the  data. 

The  disadvantage  of  existing  LED  technology  is  that  the  (flat)  X-Y  grid  requires  a somewhat  flat  surface  in 
order  to  achieve  maximum  utilization  of  a display  surface.  The  common  inexpensive  CRT  introduces  a notice- 
able parallax  problem  while  flat  surface  displays  tend  to  be  expensive.  The  disadvantage  of  the  pressure 
sensitive  method  is  that  imbedded  devices  tend  to  diminish  viewing  ability  of  displayed  data  under  low 
lighting  conditions  and  cause  reflection  problems.  In  addition,  continuously  touching  the  display  surface 
causes  finger  smears  and,  depending  on  the  display,  deterioration  of  the  surface  itself. 

Additional  research  is  necessary  to  improve  the  touch  entry/display  combination.  However,  the  current  suc- 
cess in  the  use  of  this  technique  is  evident  in  several  applications.  In  particular: 

•A  pressure  sensitive  acoustical  method  of  touch  entry  is  used  at  the  University  of  Vermont  to 
communicate  with  PROMIS  (Problem  Oriented  Medical  Information  System). 

•A  LED  method  of  touch  entry  is  used  at  the  University  of  Illinois  to  communicate  with  PLATO, 
their  Interactive  Computer  Aided  Instruction  System. 

DISPLAYS 

One  or  more  tabular  displays  can  be  provided  at  each  operating  position  to: 

•Serve  as  an  interactive  display  for  message  composition  in  conjunction  with  a touch  device  and 
software  features  as  discussed  below,  and  to  provide  a means  of  displaying  solicited  and 
unsolicited  messages  from  the  computer. 

•Serve  as  a data  display  for  the  presentation  of  information  selected  for  display  through  the 
interactive  display,  or  forced  to  the  position,  or  used  as  a reference  point  for  action 
initiation. 

The  two  most  attractive  choices  for  an  interactive  display  are  a CRT  and  a flat  panel  matrix  display.  Be- 
cause curved  surfaces  of  CRTs  can  cause  greater  parallax  problems,  their  use  with  LED  touch  entry  devices 
requires  careful  attention  in  human  factor  and  engineering  designs.  In  addition,  the  depth  of  the  tube 
makes  console  integration  difficult  in  terms  of  accessability  to  the  operator. 

Flat  panel  technologies  - e.g.,  gas  discharge,  LEDs,  liquid  crystal  matrix,  are  still  in  the  developmental 
stage  although  the  gas  discharge  method,  in  the  form  of  plasma  displays,  is  being  used  today.  However,  a 
flat  panel  display  is  preferred  for  many  applications  as  the  interactive  display  because  of  console  packag- 
ing considerations  and  minimum  parallax  problems  if  the  LED  type  touch  overlay  is  used. 

A number  of  display  devices  are  available  for  use  as  the  data  display.  Selection  of  an  appropriate  device 
is  dependent  upon  the  particular  application  and  the  human  element.  The  prime  considerations  are  display 
capacity  to  meet  operational  requirements,  console  packaging  arrangements  to  promote  readability  of  dis- 
played information,  and  of  course,  the  legibility  of  the  presentation. 

The  display  configuration  is  determined  by  the  requirements  of  the  operating  position.  Two  display/touch 
techniques  are  possible: 

•The  direct  touch  whereby  all  areas  of  display  are  touchable.  However,  if  large  quantities  of 
data  are  to  be  presented,  the  size  of  the  display  presents  a "reach"  problem  to  the  operator. 

•The  indirect  touch  whereby  a call-down  technique  is  used  to  access  data  on  a large  display 
surface.  This  requires  one  additional  touch  to  cause  the  display  of  the  referenced  data 
into  the  interactive  area  prior  to  initiating  an  input  action. 

Conceivably,  the  interactive  and  the  data  display  can  be  the  same  physical  display  unit.  However,  in  most 
cases,  the  interactive  display  is  better  suited  as  a stand-alone  unit.  In  this  case,  the  data  display  can 
be  one  or  more  physical  display  units  of  varying  size(s). 

LOCALIZED  DATA  PROCESSING 

The  cost,  flexibility  and  packaging  arrangement  of  a software/firmware  driven  micro -computer  lend  them- 
selves to  application  at  a user  position.  Direct  assistance  can  be  provided  through  software  and  firmware 
in  the  composition  of  input  messages  and  in  the  selection  and  control  of  information  presented  on  tabular 
displays.  Data  base  files  can  be  stored  within  the  memory  of  the  local  computer  to  facilitate  rapid  call-up 
of  information  not  presented  on  the  display.  A computer  at  each  user  position  can  interface  directly  with 
a host  computer  system  or  can  be  tied  to  a front  end  processor  serving  as  a concentrator  for  the  transmis- 
sion of  messages  between  the  host  and  each  localized  computer. 

SOFTWARE 

Software  resident  in  a computer  at  the  operating  position  offers  a high  degree  of  flexibility  to  support 
the  man-machine  interface.  Alternatively,  some  functions  can  be  hard-wired  (firmware)  - if  the  response 
time  requirements  so  dictate.  The  software  should  be  designed  to  provide  three  basic  functions: 

•Permit  a dialogue  between  the  operating  position  and  the  host  computer  system  for  the  purpose 
of  requesting  information,  updating  a data  base,  initiating  network  activities,  etc. 
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•Format  and  display  the  information  to  be  presented  at  the  position. 

•Provide  a means  for  local  (manual)  control  or  management  of  information  displayed  at  the  operating 
position;  for  example,  shifting  of  information  from  one  area  of  a (data)  display  to  another  area, 
deleting  displayed  information  no  longer  needed,  or  rearranging/reformatting  information  to  gain 
a different  perspective  of  the  displayed  data. 

While  common  software  can  be  implemented  for  each  operating  position,  the  use  of  adaptation  tailors  the 
operation  of  the  software  to  meet  the  needs  of  the  position  or  even  the  desires  of  the  individual  currently 
manning  the  position.  Adaptation,  in  the  form  of  tables  generated  by  support  software  and  stored  within 
the  operational  software,  can  be  used  to  support  message  entry,  display,  and  management  functions.  It  can 

provide  the  flexibility  to  change  the  operating  characteristics  of  the  software  without  changing  the  soft-  i 

ware  itself;  it  can  specify  how  and  where  information  is  to  be  presented  on  any  display  surface;  it  can 
maximize  the  use  of  the  interactive  display  for  message  entry;  and  it  can  support  each  of  the  basic  soft- 
ware functions. 

Message  Entry  Function 

Integral  to  the  interactive  display/touch  entry  concept  is  the  use  of  menus,  branching  logic,  and  implied 
logic  to  support  the  message  entry  function.  Composing  a message  for  input  to  the  system  can  become  an 
extension  of  the  thinking  process  when  the  operator  touches  displayed  information  presented  under  software 
control.  Each  of  these  features  is  discussed  in  the  following  paragraphs. 

Menus  - Menus  can  contain  lists  of  message  (type)  identifiers  and  data  necessary  for  each  message  type. 

Each  item  in  a list  can  be  positioned  on  the  interactive  display  at  one  or  more  touch  points  depending 
upon  the  number  of  characters  required  for  each  item.  In  general,  three  types  of  menus  can  be  adapted  for 
each  operating  position: 

•Tailored  menus  designed  to  meet  the  operational  requirements  of  each  position. 

•Standard  menus  designed  for  universal  use  at  all  operating  positions. 

•Real-time  generated  menus  to  support  a particular  entry  sequence  as  defined  by  the  previous 
input  selections.  This  type  of  menu  can  also  result  from  real-time  alteration  of  an  adapted 

tailored  or  standard  menu.  } 

Since  the  contents  of  each  menu  can  be  presented  under  software  control,  the  selection  of  message  data  can 
be  syntact ically  correct,  thus  reducing  the  incidence  of  format  errors  in  messages  composed  for  input  to 
the  system.  A standard  keyboard  should  be  made  available  to  enter  messages  and  data  not  available  through 

a touch  menu.  ■ 

Branching  Logic  - Special  software  branching  logic  can  be  used  in  conjunction  with  menus  to  guide  or 
prompt  the  operator  in  mer.sage  composition.  This  logic  can  control  the  presentation  of  menus  in  hierarchal 
fashion  if  more  than  one  component  or  field  of  data  is  necessary  to  complete  a message  entry  sequence. 

When  an  item  - e.g.,  message  type,  is  touched  in  one  menu,  the  next  menu  in  an  adapted  sequence  can  be 
displayed  to  permit  operator  selection  of  the  next  field  of  data.  This  process  can  facilitate  the  message 
entry  process  and  can  assure  the  logical  correctness  of  messages  input  to  the  system.  It  has  the  added 
advantage  of  teaching  the  user  the  format  and  coding  of  the  message  entry  sequences. 

Branching  logic  can  facilitate  correction  or  reinitialization  of  a previously  composed  message.  In  most 
cases,  a message  entry  sequence  can  be  designed  to  permit  selection  of  additional  or  alternate  fields  of 
data  after  the  message  has  been  composed,  but  not  yet  input  to  the  system.  In  most  systems  of  today,  the 
entire  message  composition  process  must  be  reinitialized  in  order  to  correct  a field  entered  in  error. 

The  use  of  branching  logic  with  touch  entry  can  simplify  correction  of  an  incorrect  field. 

Implied  Logic  - Further  simplification  of  the  message  entry  process  can  be  achieved  through  use  of  special 
software  logic  keyed  to  the  display  of  information  on  the  interactive  display.  This  information  can  be 
the  result  of  previous  processing  of  data  or  the  condition  of  a certain  event.  It  can  also  exist  in  the 
form  of  an  indicator  alerting  the  operator  to  a situation  requiring  his  immediate  attention.  Touching  the 
displayed  information  can  imply  an  action  which  can  result  in  automatic  generation  and  input  of  a special 
message.  In  other  words,  the  system  would  respond  based  on  the  conditions  that  exist  for  the  item  selected. 

For  example,  an  input  action  can  be  implied  when  the  operator  touches  a displayed  critical  action  indicator. 

The  system  can  respond  by  displaying  additional  data  associated  with  the  critical  action  indicator  without 
interfering  with  other  activities  such  as  message  composition  in  process. 

Implied  logic  can  also  be  used  to  initiate  an  action  to  update  information  displayed  on  the  data  display, 
to  direct  an  information  message  to  another  operating  position,  or  to  accept  a message  addressed  to  the 
position. 

Display  Function 

Special  display  logic  can  provide  the  flexibility  for  matching  display  output  with  the  needs  of  the  indi- 
vidual operating  the  position.  To  a certain  extent,  this  logic  caters  to  the  problem  of  '’informat ion  pre- 
sented in  a wrong  form  for  the  man  to  understand  and  interpret  in  relation  to  his  tasks",  (Hopkins,  V.D... 

1975). 

This  logic  can  perform  the  following  basic  functions: 

•Extract  subsets  of  data  from  stored  data  files  and  format  this  data  for  display  according  to 
adaptation  in  effect  for  the  operating  position.  It  can  respond  to  simple  touch  entry  requests 
to  present  additional  sub-sets  of  data  from  the  same  file  entry,  or  to  reduce  the  quantity  of 
information  presented.  It  can  also  provide  for  easy  call-up  of  the  total  set  of  data  available 
for  an  entry. 
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•Permit  use  of  a "scratch-pad"  area  of  the  display  for  presentation  of  memory  jogger  types  of  notes 
selectable  from  special  tailored  menus.  This  action  is  similar  to  the  current  use  of  a pencil  to 
annotate  hard-copy  output. 

•Change  the  contents  of  a data  menu  based  on  new  data  entered  through  the  keyboard. 

•Respond  to  display  management  input  actions  affecting  only  the  display  of  specific  information 
at  the  entering  position  - for  example.  Delete,  Move,  Re-sort. 

•Support  the  indirect  display/touch  technique  used  in  system's  requiring  the  display  of  large 
quantities  of  information. 

APPLICATION  TO  AIR  TRAFFIC  CONTROL 


Various  aspects  of  these  concepts  can  be  applied  to  a variety  of  systems  heavily  dependent  on  the  man- 
machine  interface.  The  ETABS  developmental  effort  currently  underway  by  the  FAA  is  an  example  of  the  ap- 
plication of  these  concepts  to  a system  like  Air  Traffic  Control.  ETABS  is  expected  to  simplify  the  message 
entry  process  and  to  provide  a means  of  displaying  pertinent  flight  and  non-flight  information  - e.g., 
meteorological  data  - on  tabular  displays  at  each  sector  position.  ETABS  is  designed  to  guide  the  control- 
ler in  composition  of  messages  for  entry  to  the  system;  to  relieve  the  controller  of  the  time  consuming  bur- 
den of  handling  flight  progress  strips,  thereby  permitting  more  time  for  tactical  and  strategic  control 
functions;  and,  to  provide  a method  for  annotating  displayed  data  similar  to  the  current  use  of  a pencil  to 
mark  flight  progress  strips. 

The  following  paragraphs  describe  in  detail  the  application  of  the  Interactive  Design  concepts  to  ETABS. 

This  application  represents  the  initial  capability  to  be  incorporated  within  the  ETABS  Engineering  Model 
for  testing  and  evaluation. 


ETABS  HARDWARE  CONFIGURATION 


The  basic  ETABS  configuration  will  consist  of  a network  arrangement  within  each  ARTCC  whereby  a micro- 
computer at  each  sector  position  is  linked  with  a mini-computer  through  high  speed  communication  lines. 
Peripherals  to  the  mini  include  magnetic  tape  drives  and  bulk  storage  disk  packs.  ETABS  has  been  specified 
to  operate  as  a subsystem  to  the  Central  Computer  Complex  (CCCj , or  independent  of  the  CCC  if  necessary. 

(The  CCC  is  a multi-processing  computer  system  supporting  radar  data  processing  as  well  as  flight  data  pro- 
cessing.) Hardware  redundancy  will  be  provided  to  assure  continuity  in  ATC  operations  in  case  of  failure. 

The  two  display  types  designated  for  each  sector  position  are: 

•A  data  display  divided  into  areas  containing  information  output  by  the  CCC  or  requested  by  the 
controller  - i.e.,  flight  information  similar  to  data  currently  output  on  flight  progress  strips, 
weather  data,  altimeter  data,  miscellaneous  information. 

•An  interactive  display  divided  into  areas  containing  data  necessary  for  controller  interaction 
with  the  system  - i.e.,  input  menus  used  for  message  composition,  responses  to  previously  entered 
messages,  a list  of  aircraft  identifications  (AIDs)  used  to  access  flight  information  displayed  on 
the  data  display  - indirect  display/touch  technique,  composed  messages  prior  to  entry,  special 
alert  information,  and  flight  plan  data. 

The  flexibility  of  ETABS  adaptation  permits  re-arrangement  of  data  (areas)  on  each  display  type  to  meet  dif- 
fering operational  requirements. 

A touch  entry  device  overlaying  the  interactive  display  will  provide  the  means  for  rapid  communication  with 
the  system.  Touch  points  will  be  specified  at  a (limited)  number  of  positions  on  the  display  to  support 
actions  consistent  with  the  area  in  which  the  data  is  displayed.  Approximately  2S6  touch  points  are  consid- 
ered sufficient  to  support  the  ETABS  functions.  A keyboard  will  be  provided  as  back-up  to  the  touch  entry 
device  for  specification  of  message  types  and  data  not  available  through  the  interactive  display. 

ETABS  SOFTWARE  ORGANIZATION 


A software  interface  package  is  required  to  interface  the  mini-computer  to  both  the  CCC  and  to  each  micro- 
computer. All  flight  data  messages  currently  output  by  the  CCC  to  the  sector  non-radar  position  plus  addi- 
tional messages  to  support  ETABS  functions,  will  be  handled  by  this  package.  This  software  will  perform 
message  distribution;  data  base  updating  and  provide  certain  fail-soft  capabilities. 

Additional  software  is  required  for  the  micro-computer  to  support  the  sector  message  entry  and  display  func- 
tions and  to  interface  with  the  mini-computer.  All  flight  data  information  currently  displayed  at  a sector 
non-radar  position  and  most  controller  input  messages  will  be  handled  by  this  package. 

Adaptation  - The  commonality  of  the  micro-computer  software  among  all  sector  positions  will  be  possible 
through  use  of  adaptation  tables.  Adaptation  will  tailor  the  software  to  meet  the  operational  requirements 
at  each  sector.  As  a minimum,  adaptation  will  be  used  to  specify  the  following: 


•The  position  and  format  of  information  presented  on  the  interactive  and  the  data  display.  In 
ETABS,  several  format  levels  will  be  used  to  enable  the  controller  to  select  the  level  or  quantity 
of  information  (fields)  to  be  displayed  in  the  flight  data  area  of  the  data  display  for  each  flight. 
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•The  menus  containing  types  and  data  to  be  used  with  the  touch  entry  device.  The  adaptation  for 
each  menu  will  identify  the  touch  point(s)  for  placement  of  each  item  on  the  interactive  display 
and  the  branching  logic  to  be  used  for  each  message  entry  sequence.  Tailored  menus  will  contain 
items  to  fit  the  needs  of  the  operating  position  - for  example,  an  altitude  menu  for  a low  alti- 
tude sector  will  list  altitudes  ranging  from  050  to  240  feet.  Standard  menus  will  contain  items 
appropriate  for  all  sector  positions  - for  example,  a list  of  weather  stations  to  be  used  to  re- 
quest; meteorological  information.  Adaptation  will  be  used  to  control  the  placement  of  data  on 
real-time  generated  menus  - for  example,  a list  of  fix  elements  to  be  used  for  a HOLD  action, 
consistent  with  the  filed  flight  plan  route  for  the  aircraft  being  placed  in  HOLD. 

•Additional  adaptation  will  be  provided  to  control  software  modifications  to  designated  menus  used 
for  multiple  choice  input  actions.  Displayed  items  will  be  cleared  from  a menu  once  a selection 
is  made  to  prevent  controller  selection  of  items  illegal  for  the  particular  message  entry  format. 
For  example,  the  flight  altitude  for  an  aircraft  may  be  specified  as  an  altitude  block.  The  first 
of  two  altitudes  must  be  at  a lower  flight  level  than  the  second.  Touching  the  first  altitude 
will  result  in  deletion  from  the  menu  of  all  altitudes  below  the  selected  altitude,  thereby  pre- 
venting controller  selection  of  an  incorrect  second  altitude  for  the  altitude  block. 
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•The  branching  logic  to  be  used  by  the  software  to  guide  the  controller  in  message  composition. 
Message  input  formats  will  be  specified  and  tied  to  displayable  items  on  menus. 

Message  Entry  Function  - Two  methods  of  identifying  a particular  message  type  will  be  used  in  ETABS: 

•Direct  action  whereby  the  message  type  will  be  specified  by  touching  the  message  identifier 
(mnemonic)  displayed  in  an  initial  state  menu. 

•Implied  action  whereby  the  message  type  will  be  implied  by  touching  a field  of  data  not  displayed 
in  a menu  on  the  interactive  display.  For  example,  a Flight  Plan  Readout  will  be  implied  and  the 
Readout  displayed  when  the  Aircraft  Identification  (AID)  is  touched;  an  amendment  to  a flight  plan 
field,  e.g.,  altitude  - will  be  implied  by  touching  the  field  displayed  in  a Flight  Plan  Readout 
Area;  a Handoff  Accept  action  will  be  implied  by  touching  the  AID  for  an  aircraft  in  handoff  to 
the  sector. 

Branching  logic  associated  with  both  actions  will  guide  the  controller  by  presenting,  in  sequence,  menus 
containing  data  to  be  selected  consistent  with  the  message  type  format  requirements.  When  data  is  touched 
in  a menu  and  added  to  the  message  type  displayed  in  a Preview  Area,  the  next  menu  will  be  presented  contain- 
ing legal  data  selections  necessary  to  complete  the  message  entry  sequence.  When  all  fields  of  a message 
type  are  specified,  the  branching  logic  will  return  the  initial  state  menu.  The  controller  can  then  ENTER 
the  composed  message  or  restart  the  message  entry  sequence  if  an  error  was  made  in  selection  of  a data  field 
from  one  of  the  menus.  The  software  will  support  total  or  partial  message  correction/reinitialization. 

Two  basic  types  of  messages  will  be  processed  by  the  message  entry  function: 

•System  messages  destined  to  the  CCC.  This  will  include  all  messages  which  can  currently  be  entered 
at  the  sector  non-radar  position. 

•ETABS  special  display  management  messages  to  be  used  by  the  controller  to  manage  the  presentation 
of  data  on  the  data  display  - e.g.,  MOVE,  SORT,  change  format  level  actions.  Special  messages 
will  be  used  to  annotate  fields  of  displayed  data,  e.g.,  pilot  report  at  altitude,  and  to  input 
control  information,  e.g.,  delivered  clearance  advisories,  in  scratch-pad  fields  within  flight 
data.  This  capability  is  similar  to  the  current  practice  of  marking  flight  progress  strips  with 
a pencil.  An  additional  feature  will  be  an  on-line  capability  to  modify  the  contents  of  a tailored 
menu  to  suit  changing  operational  conditions.  The  controller  will  designate  the  menu  to  be  changed 
by  touching  an  ETABS  direct  action  message  type,  and  will  use  the  keyboard  to  enter  the  change  to 
a touched  location  of  a menu  displayed  as  part  of  the  direct  action  sequence.  For  example,  stan- 
dard clearance  advisories  displayed  in  a menu  can  be  changed  using  this  method. 

Display  Function  - The  following  basic  tasks  will  be  performed  by  this  function: 

•Display  of  information  received  from  the  CCC  or  stored  within  the  ETABS  data  base  files. 

•Support  to  the  message  entry  function  in  the  display  of  menus  according  to  the  branching  logic, 
and  in  the  display  of  composed  messages  in  a Preview  Area  on  the  interactive  display.  Clear  text 
will  be  displayed  in  a composed  message  wherever  possible  in  place  of  message  type  mnemonics. 

•Response  to  controller  display  management  requests. 

•Processing  of  updates  to  displayed  flight  data  through  automatic  or  manual  modes  of  operation. 

•Duplication  of  critical  alert  indicators  on  both  the  interactive  and  the  data  display  to  alert  the 
controller  to  a condition  requiring  his  immediate  attention.  Touching  the  indicator  on  the  inter- 
active display  will  cause  the  display  of  an  Alert  message  into  a designated  area  of  this  display. 
For  example,  a "C”  indicator  will  be  displayed  with  flight  information  on  the  data  display  and  with 
the  aircraft  identifications  of  the  appropriate  flights  on  the  interactive  display.  Touching  the 
indicator  or  a special  touch  point  in  a designated  Alert  area  will  cause  the  display  of  a Conflict 
Alert  Message  for  the  two  aircraft  in  a potential  conflict  situation. 

Flight  data  will  be  displayed  within  the  flight  data  area  of  the  data  display  in  separate  lists  - i.e., 
Departure,  Information  and  En  Route.  The  latter  list  will  be  further  divided  into  sub-lists.  The  problem 
of  constant  fluctuations,  as  entries  are  added  or  deleted,  will  be  minimized  by  treating  each  list  and  sub- 
list as  a separate  entity.  Expansion  or  contraction  of  individual  lists  can  occur  without  disturbing  the 
remaining  display. 
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DESIGN  ILLUSTRATIONS 

Figure  1 illustrates  an  earlier  ETABS  configuration  used  at  The  MITRE  Corporation  to  evaluate  some  of  the 
ETABS  design  concepts.  It  depicts  the  direct  touch  technique  whereby  the  surface  of  both  tabular  displays 
is  touchable.  The  assigned  altitude  of  a flight  plan  is  amended  by  touching  (implied  logic)  the  assigned 
altitude  field  displayed  within  the  flight  data  on  the  lower  display,  touching  an  altitude  displayed  in  an 
Altitude  Menu,  then  entering  the  message. 

The  indirect  touch  technique  is  illustrated  in  Figures  2 through  7.  The  upper  non-touchable  data  display 
shown  in  Figure  2 contains  flight  data  presented  to  the  sector  position,  and  the  lower  touchable  inter- 
active display  contains  a list  of  AIDs  consistent  with  the  flight  data  displayed  on  the  data  display.  In 
order  to  access  flight  data,  the  AID  for  the  flight  is  touched  causing  the  full  flight  plan  (implied  action) 
to  be  displayed  in  a Flight  Plan  Readout  Area  of  the  interactive  display  and  the  AID  in  the  Preview  Area. 

This  is  shown  in  the  Figure  3 closeup  of  the  interactive  display.  Figures  4 through  7 illustrate  an  input 
sequence  for  composition  of  a HOLD  message.  The  action  is  initiated  by  touching  (implied  action)  the  coor- 
dination fix  field.  (A  direct  action  HOLD  message  type  was  not  adapted  for  inclusion  in  the  menu  shown  on 

the  right  side  of  Figure  3.)  The  HOLD  Fix  and  the  Expected  Hold  Fix  Departure  Time  are  then  selected  by 
touching  FRR  and  2140  on  subsequent  menus.  Figure  7 shows  the  composed  message  prior  to  entry  to  the  system. 

Figure  8 illustrates  a possible  design  configuration  to  be  used  for  testing  and  evaluation  of  the  ETABS  En- 

gineering Model.  It  should  be  noted  that  the  large  (data)  displays  with  a capacity  of  16,000  characters 
meet  the  current  operational  requirements  for  the  presentation  of  flight  data  at  each  sector  position. 

POTENTIAL  APPLICATIONS 

Various  aspects  of  this  interface  technology  have  been  applied  at  university  research  centers;  e.g..  Univer- 
sity of  Illinois  (PLATO  system),  and  in  air  traffic  control  systems  in  Great  Britain  and  Italy.  Other  ef- 
forts are  currently  underway.  It  is  not  the  intent  of  this  paper  to  delineate  these  efforts.  However,  it 
might  be  useful  to  identify  some  of  the  functions  within  generic  data  automation  capabilities  where  this 
technology  is  most  appropriate.  In  particular,  those  functions  heavily  dependent  upon  a dialogue  between 
the  user  and  the  computer  are  identified  below. 

Tactical  Command  and  Control  Systems 

The  basic  elements  of  military  Tactical  Systems  are  data  collection,  storage  and  retrieval,  display,  anal- 
ysis and  decision  making.  The  system  must  account  for  a wide  range  of  factors  such  as  the  current  battle 
situation,  enemy  intent,  and  force  status.  Users  at  various  nodes  in  the  system  network  must  interact  with 
the  system  and  with  local  and  central  data  base  files  under  conditions  where  timeliness  is  of  critical  impor- 
tance. 

The  interface  technology  described  in  this  paper  can  support  the  following  basic  functions: 

•Operations  Analysis  - Assistance  to  analysts  in  assessing  and  evaluating  the  conduct  and  results  of 
tactical  operations. 

•Planning  and  Decision  Making  - Providing  the  means  of  reviewing  the  status  of  enemy  and  friendly 
forces  in  a given  theatre  of  operations. 

•On-Line  Simulation  - Providing  the  means  for  selective  display  of  information  with  manipulative 
CTpability  to  simulate  various  battle  field  configurations  prior  to  selection  of  a course  of  ac- 
t.on  and  without  disturbing  the  stored  data  base  files. 

Data  Communications  Networks 

Data  communications  networks  exist  in  a variety  of  forms  and  disciplines.  There  is  an  increased  use  of  net- 
works in  both  military  and  non-military  environments.  Regardless  of  the  application,  network  response  time 
is  of  critical  importance  in  some  systems.  However,  the  response  time  is  usually  measured  as  the  time  be- 
tween actual  input  of  a message  and  receipt  of  a system  reply.  The  message  composition  time  is  not  included 
as  part  of  the  total  response  time  since  it  is  considered  an  activity  external  to  the  network  itself.  Yet, 
this  activity  is  often  more  time-consuming  than  the  actual  network  transmission  times  and  should  be  included 
as  a measured  component  of  total  network  response  times. 

The  interface  technology  described  in  this  paper  can  be  applied  to  network  operation  to  support  the  follow- 
ing basic  functions: 

•Assist  in  network  control  by  providing  real-time  information  relating  to  transient  crises  or 
rapidly  developing  network  overload  and  a rapid  means  of  adjusting  network  parameters. 

•Dynamic  control  over  the  display  and  queueing  for  display  of  messages  addressed  to  the  control 
position. 

With  an  interactive  capability  as  described  in  this  paper,  an  operator  can  respond  to  changing  network  con- 
ditions without  interfering  with  activities  at  the  position.  For  example,  an  operator  can  be  alerted  to 
situations  requiring  his  immediate  attention  without  interfering  with  message  composition  in  process. 

Data  Management/Information  Retrieval  Systems 

These  systems  exist  in  a variety  of  forms,  from  specific  application  oriented  capabilities  to  general  pur- 
pose systems  supporting  a diverse  group  of  users.  The  commonality  among  most  systems  is  in  the  basic  func- 
tions provided;  namely,  data  base  generation,  update  and  maintenance,  and  information  retrieval  and  output. 
Procedural  or  task  oriented  command  languages  are  used,  primarily  through  an  Input/Output  Typewriter,  as 
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the  interface  methodology  between  the  user  and  the  system.  This  device  is  usually  used  for  both  message 
entry  and  display  of  control  information  necessary  to  define  the  functions  to  be  performed. 

The  interface  technology  described  in  this  paper  can  support  the  basic  functions  of  a Data  Management 
System: 


•File  Generation  - The  interactive  display  together  with  the  touch  entry  device  and  menus  con- 
taining lists  of  features  supported  by  the  system  can  be  used  to  specify: 

- File  structure,  e.g.,  serial  storage,  parallel  storage,  indexed  sequential 
storage 

Data  field  definition 

- Coding  convention 
Access  levels 

- Maximum  size  of  the  file 

The  technique  used  to  access  and  define  a file  can  be  developed  in  an  interactive  touch  entry/ 
keyboard  environment.  In  particular,  a dictionary  identifying  all  the  features  of  a file  as 
well  as  trees  or  hierarchical  relationships  can  be  constructed  prior  to  generation  of  the  file. 

•File  Maintenance  - The  interactive  environment  can  be  used  to  control  the  updating  of  a file 
and  the  expansion  of  a file  to  include  additional  fields.  A dictionary  displayed  at  touch  points 
plus  generated  menus  can  be  useful  in  defining  fields  to  be  updated,  and  the  location  and  attrib- 
utes of  new  fields  to  be  added  to  a file  or  old  fields  to  be  deleted. 

•Data  Output  - The  message  composition  features  of  the  interface  technology  facilitate  the  re- 
trieval function.  Dictionary  terms  displayed  at  touch  points  plus  menus  of  message  and  compu- 
tational processing  identifiers  can  be  used  to  request  information. 


CONCLUSION 

This  paper  has  presented  an  overall  concept  for  improving  the  man-machine  interface  for  data  acquisition, 
display  and  control.  The  basic  technology  of  this  concept  exists  today  and  can  be  applied  to  a number  of 
systems  in  which  the  dialogue  between  the  user  and  the  computer  is  essential. 

Implementation  of  these  concepts  has  the  potential  for  achieving  certain  benefits  summarized  as  follows: 
•Improvement  in  total  response  time. 

•Flexibility  to  easily  modify  message  entry  and  display  functions  without  disturbing  the  basic 
structure  of  the  system. 

•Decreased  incidence  of  input  errors  corrupting  a data  base  or  prolonging  total  response  time. 

•Facilitating  the  operation  of  a position  by  tailoring  the  functional  capabilities  to  meet  the 
needs  of  that  position. 

•Simplified  training  cycles  due  to  the  self-instructional  nature  of  the  interface  design  in 
prompting  the  user  in  system  utilization. 
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DISCUSSION 


P.E. Boutin 

Could  you  characterise  the  amount  of  computer  power  and  memory  capacity  provided  at  a given  operator  station? 
Author’s  Reply 

Given  maximum  loads  and  specified  response  times,  computer  utilization  is  no  greater  than  70%  on  the  average. 
Memory  cycle  speed  is  in  the  750-800  nanosecond  range.  Memory  capacity  is  about  96  KB  which  includes  refresh 
memory  for  the  display  devices.  Memory  utilization  is  no  greater  than  80%  (allowing  room  for  expansion). 


R.C.Makin 

Can  the  operator  change  the  menu? 

Author’s  Reply 

Yes. 
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SUMMARY 


This  paper  describes  a part  of  the  "Multi sensorstudie"  which  is  performed  by  Siemens  Co. 
under  contract  of  the  German  OoD.  This  study  prepares  the  development  of  an  all-weather 
reconnaissance  system  for  tactical  ground  to  ground  missions.  At  present,  passive  elec- 
trooptical  sensors  ( TV , LLLTV  , FLIR)  , active  microwave  Sensors  (tracking  radar  RATAC, 
3-D-radar),  and  a passive  microwave  radiometer  are  combined  to  form  a multisensor  system. 
Within  this  project  our  institute  (IITB)  had  to  solve  two  problems: 

1.  The  display  of  information  of  the  3-D-radar. 

This  is  done  by  showing  a horizontal  and  a vertical  slice  of  the  spatial  scene  to  the 
observer  who  can  select  the  position  of  the  slices  as  well  as  the  displayed  depth 
range . 

2.  The  integration  of  sensory  information  from  the  different  sensors.  This  task  essen- 
tially is  solved  by  marking  spatially  corresponding  regions  in  the  different  pictures 
by  means  of  auxiliary  lines. 

During  field  measurements  the  combination  of  FLIR  and  RATAC  turned  out  to  be  very  useful. 
The  3-D-radar  could  not  yet  be  tested. 

1.  INTRODUCTION 

A modern  tactical  weapon  system  is  expected  to  operate  even  at  bad  weather  and  poor 
sight  conditions.  This  implies  the  need  of  an  all-weather  reconnaissance  system.  The 
German  DoD  has  assigned  the  Siemens  Co.  to  perform  a "Multisensorstudy"  in  order  to  get 

a basis  for  the  development  of  such  a reconnaissance  system.  The  system  should  meet  the 

following  requirements:  It  shall  be  useful  for  ground  to  ground  reconnaissance  up  to  a 
distance  of  about  S km.  Within  this  range  tactical  vehicles  and  helicopters  are  to  be 
detected  and  localized;  identification  of  the  targets  should  be  done  as  far  as  possible. 
The  system  has  to  be  mobile  and  suited  for  all-weather  operation. 

These  requirements  can  only  be  fulfilled  by  a reconnaissance  system  which  employs  diffe- 
rent technical  sensors  and  uses  their  respective  advantages.  The  combination  of  passive 
electrooptical  sensors  and  active  microwave  sensors  seems  to  be  a good  concept.  The 
e lectrooptical  sensors  have  the  advantage  of  delivering  pictures  with  high  spatial  re- 
solution. This  is  important  for  the  detection  and  identification  of  targets  and  for  the 

determination  of  their  direction.  Disadvantages  of  the  electrooptical  sensors  are  the 
limited  all-weather  capabilities  and  poor  information  about  distances.  On  the  contrary 
the  radar  delivers  good  distance-information  and  giveB  statisfying  results  even  under 
bad  weather  conditions.  Furthermore  it  allows  conclusions  about  the  radial  velocity  of 
targets  using  the  Doppler-ef feet . This  is  important  for  the  detection  of  moving  objects. 
Disadvantages  of  the  radar  are  its  poor  angular  resolution  and  the  fact,  that  it  is  an 
active  sensor.  Thus  the  electrooptical  sensors  and  the  radar  sensors  support  each  other. 
Therefore,  one  tries  to  integrate  them  into  one  system.  The  practical  value  of  such  a 
sensor  system  will  strongly  depend  on  the  capability  of  a human  observer  to  make  use  of 
the  information  from  different  sensors.  It  was  therefore  considered  how  to  display  and 
integrate  the  sensory  information  such  that  a human  observer  is  well  supported. 

These  two  tasks  - the  display  and  the  integration  of  sensory  information  - were  the 
subject  of  the  work  of  the  IITB.  Our  solutions  will  be  described  in  the  following. 

2.  SENSORS  EMPLOYED 

At  the  present  state  of  the  project  the  following  sensors  are  tested  for  their  qualifi- 
cation within  the  planned  multisensor-system. 

2.1  Electrooptical  sensors  (see  Fig.  1) 

• TV  angle  of  aperture  ca.  10°  x 7.5° 

• LLLTU  " " " " 10D  x 7.5° 

• FLIR  (8  M - 12  M)  " " " " 6°  x A0 

These  sensors  are  jointly  mounted  on  a common  gun  carriage.  TV  and  LLLTV  deliver  pictorial 

information  directly  in  CCIR-norm  while  a standards-conversion  must  be  performed  for  the 
FLIR-data.  In  the  present  state  this  is  done  by  means  of  an  intermediate  image. 

2.2  Battlefield  surveillance  radar  RATAC  (see  Fig.  2) 

The  RATAC  operates  in  the  x-band  and  has  the  capability  of  tracking  moving  targets.  Its 
outputs  are: 


• the  coordinates  of  the  target  position  (distance  d and  azimuth  a - no  information  about 


elevation) 

• a Ooppler-tone 

The  Doppler-tone  contains  information  about  the  radial  velocity  of  the  target  and  of  the 
type  of  the  target.  It  is  e.  g.  possible  to  discriminate  between  tracked  vehicles, 
wheeled  vehicles,  and  persona  by  the  characteristical  Doppler-tones. 

2.3  3-D-Radar  (see  Fig.  3) 

The  3-D-radag  operates  at  35  GHz.  It  scannes  a spatial  region  which  extends  12. B°  in 
azimuth,  3.2  in  elevation,  and  about  576  m in  distance.  The  operator  CBn  specify  the 
distance  d where  the  scanned  region  begins.  ThiB  region  iB  divided  into  128  k picture 
cells  withr64  pixels  in  azimuth,  16  pixels  in  elevation,  and  128  pixels  in  distance. 

The  results  of  the  radar-measurements  are  stored  in  a 128  k byte  RAM.  Each  byte  corres- 
ponds to  one  pixel.  Normally  7 bits  of  a byte  contain  information  about  the  echo-amplitude 
and  two  bits  contain  information  about  the  direction  of  motion  which  can  be  'coming', 
'going',  or  'zero'  (the  parity-bit  is  used  for  pictorial  information  too).  When  the  radar 
operates  in  a MTI-mode,  the  first  7 bits  contain  information  about  radial  velocity.  From 
the  stored  radar-data  appropriate  images  can  be  generated. 

2.4  Microwave-Radiometer 

Instead  of  the  35  GHz  3-0-radar  a passive  microwave-radiometer  can  be  put  onto  the  pivot 
mounting  of  the  antenna.  The  radiometer  is  still  an  experimental  system  and  was  not  yet 
included  in  our  part  of  the  work.  Therefore  it  will  not  be  described  here. 

3.  D 15 PL AY  OF  RADAR  DATA 

For  principal  and  technical  reasons  the  information  from  the  3-D-radar  is  not  displayed 
in  form  of  a stereoscopic  picture.  Instead,  two  views  of  the  scanned  spatial  region  are 
displayed  on  separate  TU-screens.  Fig.  4 shows  the  spatial  arrangement  of  the  radar  images: 

1.  Top  view: 

This  picture  shows  a plane  with  constant  elevation.  The  observer  can  select  one  out  of 
16  elevations  or  a picture  which  has  been  averaged  over  all  16  elevations. 

The  appropriate  display  is  a trapezoidal  sector-PPI,  but  for  technical  reasons  we  dis- 
play a rectangular  B-scope.  The  picture  format  is  64  x 12B  pixels. 

2.  Front  view: 

This  picture  is  referred  to  as  "range  slice".  Its  format  is  64  x 16  radar  pixelB.  We 
display  three  consecutive  range  slices  simultaneously  in  order  to  take  advantage  of  the 
whole  area  of  the TU-screen. In  this  view  the  observer  selects  the  distance  of  the  range 
slices  and  - within  certain  boundaries  - the  depth  of  the  slices. 

The  B-scope  and  the  range-slices  cover  a whole  TV-screen  each.  Therefore  the  raster  of 
64  x 16  or  64  x 128  pixels  is  rather  coarse.  Due  to  the  relative  large  pixels  it  is 
possible  to  represent  the  state  of  motion  of  each  pixel  by  slowly  flickering  directed 
triangles  which  have  the  size  of  one  radar  pixel.  So  the  addition  of  motion-symbols  causes 
no  loss  of  pictorial  information.  A disadvantage  of  the  coarse  raster  is  the  fact,  that 
such  block  pictures  are  hard  to  interprets  (HBrmon,  L.D.,  1973).  Therefore  the  rastered 
images  are  smoothed  by  means  of  a twodimensional  linear  interpolation.  The  interpolation 
is  accomplished  in  realtime  by  special-purpose-hardware.  The  symbols  and  auxiliary  lines 
in  the  radar  image  are  not  effected  by  the  smoothing  operation. 

Fig.  5 shows  the  structure  of  the  technical  solution.  The  control  panel  contains  control 
elements  for  selecting 

• the  elevation  of  the  B-scope 

• the  mean  distance  d of  the  range  slices  and  the  number  of  radar  range  gates  which  have 
to  be  summed  up  to  form  a range  slice. 

' the  zero-point  and  slope  of  a grey  scale  which  matches  the  7 bit  of  resolution  radar 
data  to  a 4 bit  of  resolution  video  image. 

From  these  settings  a microcomputer  determines  the  control  parameters  for  a special  pur- 
pose hardware  which  generates  the  radar  images.  This  concept  was  chosen  in  order  to  get 
a high  data  throughput. 

4.  INTEGRATION  OF  SENSOR  INFORMATION 

The  planned  reconnaissance  system  shall  help  a human  observer  to  detect,  localize,  and 
identify  objects  of  interest  such  as  tactical  vehicles.  With  the  multisensor  system  the 
observer  has  the  opportunity  of  gathering  all  information  available  from  an  object  of 
interest.  In  order  to  do  so  the  observer  must  know  where  to  find  the  selected  object  in 
the  different  pictures.  Our  concept  of  integrating  the  sensory  information  is  to  point 
out  where  a specified  region  of  the  observation  space  can  be  found  on  the  different 
displays  or  with  the  RATAC. 
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For  the  implementation  of  this  concept  the  gun  carriage  yith  the  electrODptical  sensors 
and  the  pivot  mounting  of  the  3-D-radar  yere  equipped  yith  angle-encoders  so  that  the 
microprocessor  knoys  yhere  the  sensors  are  looking  at  (see  Fig.  6).  In  addition  the  micro- 
processor is  informed  about  the  different  angles  of  aperture.  The  observer  can  select  a 
region  at  distance  d,  azimuth  a,  and  elevation  6 for  closer  observation  by  means  of  tyo 
joy  sticks  yhich  are  mounted  on  the  control  panel.  From  these  settings  the  microcomputer 
selects  the  B-scope  at  elevation  & and  the  range  slices  around  distance  d to  be  read  from 
the  128  k memory.  Furthermore  the  microcomputer  determines  the  position  of  several 
auxiliary  lines,  yhich  mark  the  selected  region  in  the  TV-  and  radar-images.  These 
auxiliary-lines  are  set  as  folloys: 

- Range  slices:  The  middle  slice  is  that  at  the  chosen  distance  d.  In  this  picture  the 
angles  a,  & are  marked  by  means  of  a quadratic  frame  yith  the  size  of  one  radar  pixel. 

- B-scope:  The  displayed  B-scope  is  that  one  at  the  selected  elevstion  & . Here  the 
azimuth  a ia  marked  by  a vertical  line.  The  distance  d iB  included  betyeen  tyo  horizontal 
lines  yhich  shoy  the  near  and  the  far  border  of  the  middle  range  slice.  ThiB  is  done, 
because  a range  slice  can  be  generated  by  averaging  over  1,  2,  4,  B or  16  consecutive 
range  gates  of  the  3-0-radar. 

- TV,  LLLTV , FLIR:  Similar  to  the  range  slices  azimuth  ct  and  elevation  & are  marked  by  a 
quadratic  frame.  But  in  contrary  to  the  radar  picture  the  size  of  this  frame  is  variable. 
In  order  to  encode  information  about  the  distance  d too,  the  size  of  the  quadratic  frame 
is  set  such  as  if  it  yere  the  image  of  a NATO  standard  target  (2.3  m x 2.3  m)  positioned 
at  distance  d.  This  helps  the  observer  in  detecting  and  identifying  objects  because  he  can 
check  the  proportions  of  the  object  yith  reference  to  the  standard  target. 

In  practice  the  system  is  used  in  the  folloying  yay:  The  observer  notices  an  object  of 
interest  on  one  of  the  displays.  Then  he  marks  the  object  yith  auxiliary  lines  by  means 
of  the  joy  sticks.  Because  of  that  this  object  is  marked  in  the  remaining  pictures  too. 
Furthermore  the  coordinates  of  the  object  are  sent  to  the  RATAC  so  that  the  RATAC-observer 
can  examine  this  region  immediately.  On  the  other  hand  the  RAVAC  sends  the  coordinates 
d. , a of  its  target  point  to  the  microcomputer.  If  a target  has  been  detected  by  the  RATAC, 
tne  observer  can  cause  the  microcomputer  to  take  the  coordinates  from  the  RATAC  instead 
from  his  settings  on  the  control  panel  so  that  the  RATAC-target  is  marked  on  the  displays. 

5.  EXPERIENCES 

It  is  planned  to  test  the  properties  of  the  multisensor-system  during  three  field  experi- 
ments yith  a duration  of  four  yeeks  each.  The  first  experimental  period  took  place  in 
July/August  1978  on  a military  training  camp.  At  this  time  the  development  of  the  3-D-radar 
yas  not  completed  so  that  no  radar  data  yere  available.  So  ye  have  to  restrict  ourselves 
to  a report  on  the  combination  of  the  electrooptical  sensors  and  the  RATAC.  This  combi- 
nation turned  out  to  be  very  useful.  This  yas  especially  proven  yithin  experiments  yhich 
simulated  realistic  conditions:  a tactical  vehicle  yas  hidden  jn  a distance  of  2 t 3 km 
from  the  measurement  equipment  and  then  moved  on  a zigzag  course  toyards  the  measurement 
equipment.  The  observers  were  only  told  yhen  the  vehicle  yould  start  moving.  Their  task 
yas  to  detect,  localize,  and  identify  the  vehicle  as  fast  as  possible.  Since  these  ex- 
periments yere  performed  at  night, only  the  FLIR  and  the  RATAC  gave  good  results.  The 
vehicles  alyays  yere  detected  and  localized  short  time  after  they  had  reached  an  observable 
area.  Usually  the  target  yas  first  detected  by  FLIR  and  a short  time  after  that  the  RATAC 
observer  gave  the  distance  of  the  target  and  discriminated  betyeen  tracked  vehicles  and 
yheeled  vehicles.  Yet  the  final  identification  of  the  target  yas  possible  only  by  means 
of  the  FLIR  at  relatively  short  distances. 

References: 

Harmon,  L.D.,  Scientific  American,  Nov.  1973 


DISCUSSION 


A.Clearwaters 

You  mentioned  a series  of  experiments  with  the  equipment  and  indicated  you  were  satisfied  with  the  results.  In 
what  way  were  you  satisfied?  More  specifically,  how  did  your  system  behave  relative  to  current  systems  that  do 
the  same  thing,  i.e.,  a man  with  a starlight  scope? 

Authors’  Reply 

The  multisensor  system  delivers  more  information  to  the  obsen/er  than  a current  single  sensor  system  does,  wnen 
in  your  example  a target  is  detected  by  means  of  an  electro-optical  sensor,  the  radar  can  e directed  immediately 
to  the  target  and  so  the  distance  and  the  radial  velocity  are  measured  in  addition. 
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TACTICAL  RECONNAISSANCE  IMAGE  EXPLOITATION 


Gary  L.  Wycoff 
Northrop  Corporation 
Electronics  Division 
2301  W.  120th  Street 
Hawthorne,  California  90250 
U.S.A. 

SUMMARY 


The  advent  of  improved  sensors  and  data  links  places  the  burden  of  timely  tactical  reconnaissance 
image  exploitation  and  reporting  on  the  Ground  Processing  Facility.  The  use  of  multiple  sensors 
such  as  infrared,  electro-optical,  and  radar  will  provide  a high  volume  of  imagery  data  via  digital 
data  links.  That  imagery  must  be  effectively  digested  to  produce  timely  and  accurate  target  reports 
to  the  tactical  commander. 

To  practically  and  economically  achieve  the  capability  for  exploitation  of  digital  imagery  in  real 
time,  the  performance  requirements  of  the  Ground  Processing  Facility  must  be  carefully  established. 
Examinations  must  be  made  of  the  need  for  various  image  handling  techniques  and  the  resulting  benefit 
to  the  image  Interpreter.  Through  the  selective  use  of  current  and  planned  technologies,  an  imagery 
exploitation  cycle  time  of  less  than  three  minutes  from  receipt  of  imagery  through  report  generation 
appears  to  be  realistic. 


1.  INTRODUCTION 

The  needs  of  the  tactical  commander  dictate  that  the  exploitation  of  reconnaissance  imagery  be  ac- 
complished in  near  real  time.  The  commander  faces  massive  Warsaw  Pact  forces  that  are  highly  mobile 
and  very  heavily  defended.  Timely  and  accurate  target  reports  are  essential  in  the  determination  of 
the  targets  to  strike  and  the  assets  to  employ.  Figure  1 shows  a typical  reconnaissance/strike  cycle 
where  advantage  is  made  of  cooperative  Air  Force  and  Army  reconnaissance  and  strike  information. 

To  practically  and  economically  achieve  the  seemingly  opposing  goals  of  real  time  exploitation  and 
handling  multiple  sensor  data  rates  and  formats,  the  performance  requirements  for  the  GPF  (Ground 
Processing  Facility)  must  be  carefully  established.  Trade-offs  of  the  requirements  imposed  on  each 
system  in  the  reconnaissance  and  strike  cycle  are  necessary  to  ensure  that  major  technology,  per- 
formance, and  cost  constraints  are  not  imposed  on  one  system  while  providing  only  minor  relief  for 
another  system.  The  chain  of  events  in  the  reconnaissance  and  strike  cycle  is  depicted  in  Figure  2 
where  each  major  system  is  shown  as  a link.  The  design  goal  is  to  achieve  a balance  of  system  re- 
quirements where  a weak  link  does  not  exist  even  though  many  factors  strain  each  link's  performance. 
For  example,  the  use  of  an  airborne  image  screening  device  that  selects  only  a portion  of  the  total 
imagery  for  transmission  to  the  ground  would  reduce  the  volume  of  data  and,  hence,  the  bandwith  re- 
quirement of  the  data  link.  The  corresponding  reduction  of  imagery  flowing  into  the  GPF  would  then 
allow  the  image  interpreter  to  concentrate  on  the  more  meaningful  images  and  thus  reduce  the  workload. 
However,  today's  technology  has  not  yet  produced  a totally  effective  airborne  image  screener.  One 
alternative  is  to  incorporate  the  image  screening  device  into  the  GPF  where  the  restrictions  of  size, 
weight,  power,  etc.,  are  somewhat  less  stringent.  In  this  case,  the  interpreter  retains  the  benefits 
of  a reduced  volume  of  imagery,  but  the  data  link  bandwidth  has  not  been  lessened. 

Similar  thought  must  be  given  to  all  design  objectives  for  the  GPF  such  as  increased  timeliness  and 
accuracy  of  reports,  reduction  in  image  interpreters'  training,  and  allowing  for  an  orderly  transi- 
tion from  existing  systems  to  the  use  of  future  technologies.  Only  by  consideration  of  all  per- 
formance parameters  along  with  applicable  technical  developments  will  the  system  performance  re- 
quirements for  a tactical  ground  image  processing  facility  be  successfully  established. 


2.  TACTICAL  RECONNAISSANCE  MISSIONS 

The  tactical  reconnaissance  mission  is  the  key  factor  in  establishing  the  performance  required  of 
the  Ground  Processing  Facility  and  other  sensor  systems.  The  density  and  mobility  of  Warsaw  Pact  forces 
in  the  Central  European  theater  provide  ample  opportunity  for  obtaining  reconnaissance  imagery  that  is 
saturated  with  targets.  A basic  mission  would  typically  call  for  low  and  fast  penetration  beyond 
the  FEBA  to  obtain  high  resolution  imagery  on  potential  targets.  By  taking  advantage  of  multi-sensor 
cueing,  the  overall  volume  of  imagery  will  be  reduced  and  the  imagery  that  is  received  will  contain 
primarily  targets  of  interest.  Therefore,  the  target  detection,  classification,  and  reporting  processes 
can  be  accomplished  easier  and  faster. 
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3.  IMAGE  INTERPRETATION  CONCEPTS 

The  next  generation  tactical  reconnaissance  image  interpretation  facility  will  be  an  all-digital 
operation  utilizing  soft  copy  displays  for  both  imagery  and  text.  The  versatility  and  speed  of 
digital  image  processing  allows  the  requirements  for  the  Ground  Processing  Facility  to  be  specified 
in  a manner  that  is  practical  and  cost  effective.  Top-level  functions  of  the  GPF  are  shown  in  Figure  3. 

As  is  normal  in  initial  system  definitions,  the  performance  requirements  are  driven  by  both  the  system 
inputs,  in  this  case  the  imagery  and  associated  data,  and  the  system  outputs,  or  reports  for  the  tacti- 
cal commander. 

3.1  Ground  Processing  Facility  Inputs 

The  reconnaissance  mission  requirements  dictate  that  the  GPF  must  be  capable  of  handling  high  volume 
multi-sensor  digital  imagery.  Data  rates  in  the  order  of  50  megabits  per  second  and  above  are  anticipated. 
In  addition,  imagery  resolution  of  better  than  4000  pixels  (picture  elements)  per  line  with  a six-to-eight 
bit  gray  level  per  pixel  should  be  accommodated  and  must  be  effectively  utilized  in  the  image  interpre- 
tation process. 

A second  type  of  input  to  the  GPF  will  be  external  all-source  data  base  information  used  to  establish 
the  initial  target  area  baseline  and  to  provide  intelligence  updates  that  are  in  addition  and  comple- 
mentary to  the  imagery  inputs. 


3.2  Ground  Processing  Facility  Outputs 

The  ability  to  generate  timely  and  accurate  target  reports  is  the  GPF's  reason  for  existence.  The 
reports  will  vary,  depending  on  the  user,  in  size  and  information  content  and  also  in  the  time  required 
to  produce  them.  Small  reports  such  as  a HOTPHOTOREP  will  nominally  contain  approximately  a hundred 
characters,  but  must  be  produced  in  a few  minutes  from  receipt  of  the  raw  imagery.  Higher  command 
levels  may  only  require  daily  reports,  but  these  types  of  reports  will  be  more  comprehensive. 


A report  will  normally  contain  a textual  summary  of  the  exploited  imagery.  However,  the  GPF  can 
easily  provide  a port  for  transmission  of  an  exploited  and  annotated  digital  image  to  accompany  the 
text  or  for  real  time  display  at  a remote  location. 


The  GPF  will  also  provide  outputs  to  remote  data  bases  to  periodically  update  the  tirget  situation  and 
enhance  the  real  time  knowledge  of  the  battlefield  at  higher  corimand  levels. 


3.3  Ground  Processing  Facility  Functions 

The  GPF  must  perform  a variety  of  functions  in  order  to  accept  multi-sensor  digital  imagery  and  produce 
near  real  time  target  reports  in  the  tactical  environment.  A functional  block  diagram  for  such  a system 
is  shown  in  Figure  4.  a brief  explanation  of  each  of  the  major  functions  will  be  presented. 

The  interface  buffer  accepts  incoming  digital  imagery  and  associated  data  such  as  time  and  geographical 
position.  The  data  is  buffered  and  formatted  for  subsequent  use.  A critical  consideration  is  that 
the  imagery  buffer  be  specified  in  a modular  fashion  to  accommodate  future  sensor  systems  without  a 
large  Impact  on  the  GPF. 

Image  storage  is  basically  the  function  of  preserving  the  incoming  and  exploited  imagery  for  historic 
purposes.  As  new  imagery  is  received,  it  will  be  stored  for  later  reference.  As  images  are  inter- 
preted, they,  too,  may  be  stored  for  later  reference  by  the  interpreter  or  for  automatic  processing 
such  as  change  detection. 

i 

In  order  to  accommodate  the  incoming  volume  of  imagery,  it  is  necessary  to  have  automated  techniques 
that  relieve  the  interpreter  of  a portion  of  the  exploitation  burden.  A great  deal  of  relief  will  be 
provided  by  the  feature  extractor.  This  device  performs  automatic  image  screening  in  real  time.  The 
level  of  screening  is  selectable  by  the  image  interpreter  and  would  range  from  relatively  simple 
tasks  such  as  detection  of  man  made  objects  to  more  complex  tasks  such  as  detection,  classification, 
and  identification  of  specific  pre-selected  targets.  An  example  of  the  latter  type  of  target  would  be 
not  merely  a tank,  but  also  the  class  and  model  of  the  tank.  Other  functions  that  may  be  performed  by 
the  feature  extractor  are  image  quality  assessment  where  image  quality  below  a minimum  standard  would 
cause  automatic  storage  without  interpreter  viewing,  optimized  target  presentation  where  a target  is 
automatically  located  and  centered  on  the  interpreter's  display  at  some  desired  ground  resolution,  and 


automatic  change  detection  where  new  imagery  is  automatically  measured  and  statistically  compared  to 
historic  Imagery  contained  in  the  local  data  base. 
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A promising  approach  to  automatic  feature  extraction  involves  edge  processing  of  an  image  and  the 
measures  and  statistics  derived  from  the  resulting  edge  map.  (ROBINSON,  G.  S..,  1976)  A number  of 
edge  operators  have  been  developed  (e.g.,  Sobel , Kirsch,  Compass  Gradient  Masks)  and  some  have  been 
effectively  implemented  in  real  time  hardware.  (ROBINSON,  G.S.  AND  REIS,  J.J..,  1977)  The  measures 
taken  on  an  image  would  include  parameters  such  as  edge  length,  edge  directions,  edge  straightness/curva- 
ture, and  length-width  ratios.  By  comparing  these  measures  against  predetermined  measures  for  various 
features  or  targets,  it  may  be  possible  to  automatically  classify  objects  in  an  image. 

The  sub-picture  extractor  is  another  key  element  that  will  relieve  the  interpreter's  burden.  By  working 
in  conjunction  with  the  feature  extractor,  the  sub-picture  extractor  will  condense  the  incoming  imagery 
for  search  and  detection  operations  by  the  interpreter  at  full  field-of-view  and  reduced  resolution. 

The  sub-picture  extractor  will  also  automatically  present  an  image  to  the  interpreter  that  is  full  re- 
solution and  reduced  field-of-view  with  the  target  centered  on  the  display.  The  interpreter  may  then 
concentrate  on  the  exploitation  task  rather  than  spend  time  scanning  imagery  containing  no  targets  of 
interest. 


The  actual  image  that  is  presented  to  the  interpreter  is  contained  in  the  refresh  memory.  The  image 
is  in  digital  form  and  the  size  of  the  image  display  dictates  the  size  of  the  refresh  memory.  Func- 
tionally, the  refresh  memory  is  constantly  updating,  or  refreshing,  the  image  on  the  interpreter's  soft 
copy  image  display. 

Real  time  image  enhancement  will  increase  the  productivity  of  the  interpreter.  Enhanced  images  allow 
the  human  to  more  easily  and  quickly  recognize  information  that  was  contained,  but  hidden,  in  the  raw 
imagery.  Many  image  enhancement  algorithms  have  been  developed.  Some  of  these  would  be  gray  scale 
stretching,  digital  filtering  for  edge  sharpening,  geometric  correction  to  compensate  for  sensor-induced 
distortions,  and  magnification  of  the  imagery.  One  of  the  most  widely  used  techniques  to  date  and  one 
that  is  also  easily  implementable  in  a real  time  system  is  gray  scale  stretch  or,  in  other  terms,  the 
alteration  of  the  contrast  of  the  imagery. 

Another  useful  tool  in  the  image  exploitation  process  is  alphanumerics  and  graphics  as  overlays  on  the 
image  being  interpreted.  Symbols  such  as  circles,  triangles,  coordinate  grids,  north  arrows,  etc.,  may 
be  shown  on  the  image  display  either  automatically  by  the  feature  extractor  or  as  inserted  by  the  inter- 
preter. These  symbols  would  be  used  to  highlight  and  explain  features  and  targets  of  interest. 

The  digital  mixer  combines  the  original  and  enhanced  image  with  the  selected  alphanumerics  and  graphics. 
The  product  is  a fully  enhanced  and  annotated  digital  image  that  is  available  in  real  time  for  inter- 
preter viewing,  storage,  hard  copy  generation,  and  transmission  to  a remote  location  for  observation  by 
other  personnel . 


The  system  processor  performs  the  overall  data  management  functions.  It  provides  the  interfaces  with 
remote  all-source  data  bases  and  with  the  appropriate  c3  systems.  It  also  maintains  the  local  data 
base  within  the  GPF  where  recent  target  data  are  contained.  Tasks  such  as  data  routing  and  timing 
control,  automated  report  formatting  and  generation,  data  base  maintenance,  and  display  and  terminal 
servicing  will  be  accomplished  on  a routine  basis. 

The  most  visible  element  in  the  GPF  is  the  image  display  and  operator  console.  It  is  here  that  the 
interpreter  performs  the  image  exploitation  and  reporting  tasks.  Because  of  time  constraints,  the 
interpreter  must  be  able  to  view  the  imagery  and  supportive  text  from  one  operating  position.  The 
imagery  is  presented  on  a large  field-of-view  soft  copy  display.  The  spacing  between  pixels  on  the 
imagery  display  is  such  that  each  pixel  is  resolvable  by  the  human  eye  to  permit  the  interpreter  to 
utilize  the  maximum  amount  of  information  contained  in  the  image  when  viewed  at  full  resolution. 

The  related  textual  information  is  presented  to  the  interpreter  on  one  or  two  adjacent  soft  copy 
displays.  The  text  contains  image  related  data  such  as  previous  reports  or  target  information  from 
SIGINT  or  HUMINT  sources.  Also  presented  on  the  text  displays  would  be  the  report  format  in  a form 
that  would  allow  the  interpreter  to  merely  "fill  in  the  blanks"  with  the  necessary  information.  The 
processor  would  then  automatically  generate  and  distribute  the  report  in  the  correct  format.  Other 
aids  available  to  the  interpreter  at  the  console  are  a full  alphanumeric  keyboard,  a light  pen  to  use 
as  an  "electronic  grease  pencil"  for  image  annotations,  a joystick  for  image  manipulation  and  control, 
and  the  necessary  system  mode  controls. 


4.  RECONNAISSANCE  INFORMATION  FLOW 

The  concepts  for  the  Ground  Processing  Facility  described  above  lead  to  a system  that  is  very  responsive 
to  the  real  time  image  exploitation  requirements.  Just  how  responsive  the  GPF  will  be  in  actual  battle- 
field conditions  will  obviously  depend  in  part  on  the  performance  of  the  sensor  systems  and  the  report- 
ing constraints.  However,  the  GFP  will  not  be  the  weak  link  in  the  reconnaissance  chain  if  the  require- 
ments are  properly  identified  and  met. 


\ 
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As  a measure  of  performance,  a typical  sequence  of  events  in  the  exploitation  process  will  be  postulated 
in  an  attempt  to  quantify  the  performance.  Assume  a relatively  simple  single  sensor  input  where  digital 
imagery  is  being  continuously  received  at  a rate  of  sixty  megabits  per  second.  The  image  is  5000  pixels 
per  line  (image  width)  and  received  at  2000  lines  per  second  with  6 bits  per  pixel  gray  level  (64  gray 
levels). 


Figure  5 depicts  the  information  flow  through  the  GPF  showing  the  major  functions  and  their  associated 
times.  Imagery  is  received,  buffered,  and  stored.  A target  related  image  is  then  automatically  selected 
and  optimized. for  display  through  the  feature  extractor  and  sub-picture  extractor,  enhanced  for  optimum 
image  contrast,  overlayed  with  geographic  coordinates  and  target  symbols  indicating  the  type,  quantity 
and  location  of  targets  in  the  image,  and  displayed  on  the  image  display  in  approximately  two  seconds. 
Meanwhile,  the  system  processor  has  queried  the  data  base  for  other  reconnaissance  reports  and  would,  for 
example,  overlay  a suspected  SAM  installation  in  the  image  with  an  ellipse  graphic  indicating  the  geo- 
graphical position  of  an  ELINT  detection  by  another  sensor  system.  The  standard  report  format  will  also 
have  been  posted  on  the  text  displays. 


The  image  exploitation  and  reporting  functions  that  follow  obviously  consume  the  vast  majority  of  the 
time  from  receipt  of  an  image  until  the  target  report  is  generated  for  dissemination  to  the  appropriate 
decision  makers.  However,  by  establishing  the  performance  requirements  for  the  GFP  with  consideration 
that  the  goal  is  to  aid  the  interpreter  in  completing  the  image  exploitation  process,  a completed  report 
produced  in  less  than  three  minutes  may  be  possible. 


5.  OPERATIONAL  CONSIDERATIONS 

Operational  usability  of  the  GFP  is  dependent  on  many  factors.  The  technology  to  implement  the  required 
functions  is  now  available  or  will  be  within  the  near  future.  But  the  reconnaissance  systems  in  use  today 
in  NATO  cannot  be  ignored.  There  must  be  an  orderly  transition  utilizing  those  assets  that  are  currently 
available.  Empiisis  must  also  be  placed  on  a system  configuration  that  is  physically  deployable  in  a 
tactical  environment.  The  demands  of  size,  weight,  power,  electromagnetic  compatibility,  transportability, 
etc.,  must  be  met.  Finally,  even  though  many  image  processing  functions  will  be  automated  in  the  future, 
the  GPF  requirements  must  evolve  around  the  capabilities  and  limitations  of  the  human  image  interpreter. 


6.  CONCLUSIONS 


A near  real  time  reconnaissance  capability  is  required  for  digital  imagery  exploitation  and  report  dis- 
semination in  the  tactical  environment.  The  imagery  will  be  supplied  from  advanced  IR,  radar,  and  electro- 
optical  sensors  in  near  real  time.  A Ground  Processing  Facility  that  accepts  the  sensor  data  and  provides 
the  necessary  functions  for  a human  interpreter  to  exploit  the  imagery  and  generate  target  reports  almost 
in  real  time  is  achievable.  Some  basic  functional  elements  that  would  aid  the  image  interpreter  are  a 
feature  extractor  to  screen  the  incoming  imagery  and  display  only  annotated  target  related  imagery  and  an 
automated  report  generation  and  dissemination  technique.  The  critical  factor  in  defining  the  performance 
requirements  for  elements  of  the  Ground  Processing  Facility  is  that  each  element  must  improve  the  speed 
and  accuracy  of  the  total  exploitation  process.  The  effects  of  all  elements  on  the  performance  of  the 
facility  must  be  integrated  if  the  net  result  is  to  be  a set  of  viable  and  realistic  performance  require- 
ments. 
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Fig.l  Tactical  concepts 
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Fig.4  Ground  processing  facility  block  diagram 


Fig.5  Ground  processing  facility  information  flow  diagram 


DISCUSSION 


D.  Bosnian 

The  image  bit  rate  is,  as  you  said,  60  Mbit/sec  for  your  example  of  system  performance.  Is  this  bit  rate  the  result 
of  a compromise  or  design  constraint? 

Author’s  Reply 

No.  The  overall  digital  data  input  rate  of  60  Mbit/sec  is  not  a compromise  or  the  result  of  any  GPF  constraint. 
The  GPF  hardware  and  software  can  accomodate  a much  much  higher  input  bit  rate.  Rather,  the  60  Mbit/sec 
data  input  rate  was  chosen  merely  as  an  example  to  represent  an  input  baseline  against  which  the  GPF  functions 
and  their  elapsed  times  could  be  measured. 
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1.  Summary 

Recent  advances  In  design  technology  have  proven  critical  In  making  Time  Division  Multiple  Access  (TDMA) 
systems  feasible  for  tactical  applications.  The  challenge  In  these  applications  has  Increased  as  a severe  electronic 
warfare  (EW)  environment  has  forced  the  introduction  of  highly  complex  transmitter  and  receiver  functions  to  realize 
secure  antijam  signaling.  In  addition  to  the  complex  processing  attendant  to  the  integration  of  communications,  navi- 
gation, and  identification,  the  antijam  signaling  must  be  implemented  within  stringent  size,  weight,  and  power 
constraints. 

This  paper  deals  with  the  technology  in  two  TDMA  systems  as  well  as  Hughes'  projections  of  impacts  of  technology 
trends  on  such  systems.  The  signal  processing  techniques  discussed  include  direct  sequence  pseudonoise  modulation, 
frequency  hopping,  interleaved  forward  error  correction  coding,  and  residual  error  detection  coding.  Circuit  appli- 
cations include  (1)  programmable  matched  filters  for  burst  message  preamble  reception,  (2)  small  sized,  precise, 
agile,  rapidly  stabilizing,  digitally  controlled  frequency  synthesizers,  (3)  digital  symbol  demodulators,  (4)  surface 
acoustic  wave  (SAW)  devices,  and  (5)  automated  network  management. 

2.  The  Tactical  TDMA  System 

In  certain  civilian  contexts  the  term  TDMA  has  come  to  be  identified  with  "packet  switching, " or  the  relaying  of 
burst  messages  in  a distributed  multiple  user  communications  system.  The  tactical  TDMA  system  performs  the  same 
communications  relay  function  for  widely  dispersed  users  who  may  be  in  constant  motion.  It  also  provides  them  the 
navigation  (position  location)  and  identification  functions.  In  the  most  advanced  TDMA  systems  these  are  accomplished 
with  a single  piece  of  equipment,  using  a single  integrated  waveform. 

The  communications  links,  usually  UHF  or  microwave,  are  exposed  to  a potent  electronic  warfare  (EW)  environ- 
ment containing  high  powered  brute  force  jammers,  spoof  jammers,  electronic  signal  interceptors,  and  direction 
finders.  The  TDMA  transmissions  must  be  made  as  immune  as  possible  from  all  these  EW  measures.  Now  the 
simple  strategem  of  increasing  friendly  transmitter  power  is  clearly  Inappropriate  against  spoof  jammers,  intercep- 
tors, and  direction  finders.  Against  modem  brute  force  jammers  (who  may  enjoy  the  advantage  of  short  range  to 
their  victims)  the  friendly  transmitter  power  is  also  inadequate  unless  combined  with  spread  spectrum  signaling.  In 
some  systems  the  friendly  antennas  are  made  highly  directional  to  provide  antijam  protection,  but  in  TDMA  the  func- 
tions of  communications  relaying,  navigation/position  location,  and  identification  require  that  each  user  maintain 
alertness  to  all  other  user  transmissions.  The  distribution  of  users  over  a wide  geographic  area  and  the  need  to 
maneuver  will  deny  the  possibility  of  directional  antennas.  The  remaining  means  available  to  gain  immunity  from  EW 
is  the  design  of  a jam  resistant,  intercept-resistant  spread  spectrum  signal.  Such  signals  are  almost  universally 
found  in  tactical  TDMA. 

The  spread  spectrum  TDMA  signals  used  in  Hughes  systems  combine  the  techniques  of  direct  sequence  pseudo- 
noise (PN)  spreading  and  frequency  hopping.  These  signals  offer  the  following  features: 

(1)  Only  one  user  radiates  at  a time,  eliminating  the  possibility  of  a "near/far”  problem.  In  other  words,  the 
reception  of  distant  transmissions  can  never  be  corrupted  by  strong  friendly  transmissions  from  a nearby  unin- 
tentionaUy  competing  transmitter.  The  near/far  problem  can  occur  in  other  types  of  systems,  such  as  frequency 
division  multiple  access  (FDMA)  systems  with  imperfect  adjacent  channel  filtering  and  imperfect  spectrum  shap- 
ing. The  same  problem  always  threatens  a "code  division  multiplex"  system  if  the  ratio  of  the  distant  trans- 
mitter's range  to  the  competing  friendly  transmitter's  range  is  great  enough.  Only  TDMA  is  immune  from  near/ 
far  problems. 

(2)  All  users  occupy  full  system  bandwidth  for  maximum  antijam  processing  gain  and  low  probability  of  intercept. 
In  both  of  the  Hughes  TDMA  systems  to  be  discussed  the  combination  of  direct  sequence  pseudonoise  (PN)  modu- 
lation and  frequency  hopping  does  cause  the  user  signal  to  occupy  the  full  system  bandwidth. 

(3)  The  high  rate  PN  spreading  facilitates  tlme-of-arrival  measurements.  In  both  of  the  TDMA  systems  to  be 
discussed  the  PN  chip  rate  (keying  rate)  is  5 megachip.  The  propagation  distance  covered  by  one  chip  (minimal 
signal  element)  is  200  feet,  and  under  optimum  conditions  the  transmitter- receiver  range  can  be  resolved  to 
support  most  tactical  positioning  applications. 

The  Hughes  systems  to  be  discussed  are  called  PLRS  and  JTIDS.  The  Position  Location  Reporting  System  (PLRS) 
enables  Army  and  Marine  Division  Commanders  to  monitor  the  positions  of  units  under  their  own  command  in  real 
time,  and  enables  these  units  to  exchange  a limited  amount  of  other  critical  data.  The  Joint  Tactical  Information 
Distribution  System  (JTIDS)  is  an  Integrated  communications,  navigation,  and  identification  system  to  serve  military 
users  possibly  dispersed  over  hundreds  of  miles.  Both  PLRS  and  JTIDS  use  secure  anti-jam  communications  tech- 
niques including  direct  sequence  pseudonoise  modulation,  frequency  hopping,  interleaved  forward  error  correction 
coding,  and  residual  error  detec..jn  coding. 

2.  1 The  PLRS  System 

PLRS  is  a portable  position  location  and  navigation  system  using  TDMA  technology  to  provide  real-time  position 
tracks  on  hundreds  of  ground  and  air  user  units  within  an  Army  Division.  To  the  field  user,  PLRS  is  a small  box 
with  an  antenna  and  an  input/output  device.  It  lets  both  him  and  his  commander  know  where  he  is,  and  provides  him 


•These  systems  are  being  developed  under  U.S.  Army  contract  DAAB07-76-C-1750  ind  U.S.  Air  Force  contract 
F19628-75-C-0205. 
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access  to  the  common  user  data  base  at  the  master  unit.  To  the  commander,  PLRS  is  an  electronic  map  which 
represents  the  exact  Location  of  all  of  the  PLRS  equipped  units  within  his  area.  Users'  locations  are  known  to  within 
a few  meters,  and  each  can  send  and  receive  information  through  relays  when  no  direct  line-of-sight  path  exists  to  the 
master  unit. 


The  system  is  made  up  of  two  different  types  of  units.  The  Master  Unit  (MU)  controls  a network  of  a few  hundred 
user  units  and  provides  a central  display  of  their  locations.  The  user  unit  (UU)  is  designed  for  manpack  operation. 
However,  functionally  and  physically  identical  units  are  employed  in  aircraft,  helicopters,  or  ground  vehicles  using 
appropriate  installation  kits.  Each  unit  consists  of  all  of  the  equipment  necessary  to  enable  its  location  by  the  master 
unit  and  to  send  and  receive  digital  messages.  Both  the  MU  and  UU's  are  designed  for  operation  in  hostile  electro- 
magnetic environments.  Figure  1 shows  the  zones  of  high  density  of  manpack  user  units  and  the  zone  of  deployment 
for  master  units  within  an  Army  area. 


Each  user  transmits  a self-identifying  signal  burst  on  a precision  time-ordered  schedule,  measures  time-of- 
arrival  (TQA)  of  the  other  UU  transmissions,  and  automatically  relays  these  measurements  in  time  slots  in  which  the 
MU  has  "preprogrammed"  it  to  do  so.  The  MU  computes  and  continuously  updates  the  position  of  each  UU.  Figure  2 
illustrates  this  process. 

Position  locations  of  every  PLRS-equlpped  unit  may  be: 


• Remoted  and  displayed  at  Command  and  Centers  for  decision  making. 

• Sent  to  PLRS  UU's,  either  automatically  or  on  request. 

• Displayed  in  the  MU  for  network  management  and  technical  control. 

Position  location  and  navigation  information  exchange  between  the  MU  and  any  specified  UU  is  performed  by  means 
of  PLRS- formatted  digital  messages.  Additionally,  a limited  free-text  message  transfer  capability  is  provided.  All 
PLRS  messages  transmitted  are  cryptographically  secure  and  identical  in  their  spectral  signature  regardless  of  their 
content. 


Because  it  utilizes  composite  frequency-hop  direct  sequence  spread  spectrum  techniques,  PLRS  possesses  inher- 
ently high  jam  resistance  and  can  operate  In  hostile  electromagnetic  environments. 

2.2  The  JTIDS  System 

JTIDS  is  a time  division  multiple  access  communications  system  designed  to  operate  in  the  960-1215  MHz  TACAN 
band.  It  provides  the  military  services  with  a secure  antijam  data  link  to  operate  in  the  tactical  environment  of  the 
1980's,  spanning  a geographic  area  of  up  to  500  miles. 

The  time  division  aspect  of  system  architecture  allows  multiple  users  to  participate  in  the  communications  net- 
work. The  parameters  of  the  system  waveform  (to  be  discussed  later)  are  strongly  influenced  by  data  communications 
transfer  rate  requirements.  This  contrasts  with  PLRS,  where  the  waveform  is  designed  primarily  for  position  location. 

Each  terminal  in  the  JTIDS  network  is  assigned  a number  of  time  slots  in  which  it  can  broadcast  or  relay  messages. 
In  the  distribution  concept  shown  in  Figure  3,  all  terminals  in  the  net  can  listen  to  all  time  slots  in  which  they  are  not 
transmitting.  Code  division  multiplexing  can  be  used  to  provide  multiple  communication  networks  which  have  overlap- 
ping coverage  patterns.  A terminal  can  switch  between  multiple  networks  on  a time  slot  by  time  slot  basis.  The  ter- 
minals have  the  capability  of  transmitting  and  relaying  both  formatted  messages  and  free  text  messages  (i.  e. , for  digi- 
tal voice  and  TTY).  Position  messages  which  define  the  position  and  position  quality  of  the  user  are  transmitted  regu- 
larly to  support  the  multilateratlon  function  which  will  be  included  in  the  production  terminals. 

2. 3 The  Waveform  Architecture  cf  PLRS  and  JTIDS 

The  common  waveform  architecture  in  PLRS  and  JTIDS  reflects  the  similarities  in  the  general  requirements  on 
the  two  systems,  and  the  differences  in  waveform  parameters  reflect  both  the  differences  in  the  detailed  requirements 
and  the  contrasts  in  the  environments  of  the  systems.  The  waveform  parameters  also  carry  significant  implications 
for  hardware  implementation. 


The  cyclic  transmissions  are  organized  into  a hierarchy  of  epochs,  frames  (as  in  PLRS  or,  alternatively,  cycles 
in  JTIDS)  and  time  slots.  This  scheme  is  illustrated  in  Figure  4. 

2.3.1  The  PLRS  Waveform  Parameters 

The  PLRS  time  division  structure  simultaneously  accommodates  both  minimum  and  maximum  update  users. 

These  range  from  manpack  units  requiring  update  rates  approximately  once  every  minute  to  high  performance  fixed- 
wing  aircraft  with  desired  updates  30  times  per  minute.  This  wide  range  of  update  rates  can  be  effectively  accom- 
modated within  an  epoch  and  frame  timing  structure  which  also  provides  as  many  time  slots  as  practical  to  service  a 
5-community  network  of  over  370  users  per  community.  The  PLRS  parameters  are  shown  in  Figure  5. 

The  fundamental  time  division  of  the  system  is  the  time  slot.  Within  a single  PLRS  community,  only  one  normal 
data  message  transmission  is  allowed  in  a time  slot.  The  normal  mode  is  one  transmission  per  time  slot  with  multi- 
ple receptions  of  that  transmission.  The  time  slot  length  is  about  2 ms.  The  burBt  transmission  accounts  for  800  ps, 
and  630  ps  is  allocated  to  RF  propagation  delay.  The  balance  of  the  time  is  required  for  processing  overhead  such  as 
message  encoding,  validation,  and  guard  time. 

The  PLRS  frame  contains  128  time  slots  and  is  1/4  second  long.  The  significance  of  the  frame  is  that  it  repre- 
sents the  highest  rate  at  which  a unit  can  be  programmed  to  transmit  a user  measurement  report  (UMR).  That  is,  a 
unit  can  be  programmed  to  perform  a set  of  functions  including  a set  of  up  to  four  relay  actions,  a set  of  up  to  four 
TOA  measurements,  and  a report  transmission  as  often  as  once  every  frame  (every  250  ms). 


The  epoch  is  the  largest  time  division  which  is  significant  to  the  PLRS  network.  The  longest  Interval  for  which  a 
unit  can  be  programmed  to  repetitively  transmit  its  own  UMR  is  once  every  256  frames,  which  equals  once  per  epoch. 
The  epoch  is  64  seconds  long.  The  net  can  be  said  to  be  periodic  with  respect  to  the  epoch.  The  programmed  cyclic 
transmissions  and  receptions  do  not  change  from  epoch  to  epoch  unless:  1)  the  MU  alters  a unit's  program  for  net 
reconfiguration  purposes,  2)  a unit  is  brought  into  the  net,  or  3)  a unit  loses  radio  contact  with  the  net. 

Each  user  unit's  clock  keeps  track  of  time  in  time  slots  and  frames.  By  so  doing,  each  unit  can  be  programmed 
to  perform  specific  actions  (transmit,  receive,  measure  TOA,  etc.)  in  each  epoch. 

2.3.2  The  JTIDS  Waveform  Parameters 

Figure  6 shows  how  time  in  JTIDS  is  divided  into  time  slots,  cycles,  and  epochs.  Time  slots  for  transmission 
are  generally  made  on  the  basis  of  2N  time  slots  per  12.8-minute  epoch,  where  N can  vary  from  0 to  15  (1. e. , from 

1 to  32,768  time  slots  per  set  per  epoch).  The  repetition  rate  of  time  slots  is  compatible  with  the  75  x 2N  bits/second 
standard  transmission  rates  for  TTY  instruments.  The  7. 8 12f -millisecond  time  slot  is  partitioned,  as  in  PLRS,  be- 
tween the  burst  transmission  and  the  propagation/guard  times. 

Further  details  of  the  JTIDS  waveform  are  worth  considering  for  their  hardware  implications.  Figure  7 shows 
that  the  3354-ps  transmission  burst  comprises  129  symbols,  each  of  duration  26  ps.  Each  symbol  consists  of  1 or 

2 pulses,  each  of  duration  6.4  ps.  The  transmitter  executes  a frequency  hop  for  every  pulse,  or  one  hop  per  13  ps. 
Note  the  contrast  with  PIRS,  which  dwells  for  800  ps  on  the  same  frequency.  Also,  the  JTIDS  propagation/guard 
time  is  4.4585  ms  as  compared  with  1.2  ms  for  PLRS.  This  difference  reflects  the  contrast  in  typical  geographic 
separations  between  users,  tens  of  kilometers  in  PIRS  versus  hundreds  of  miles  in  JTIDS. 

3.  Hardware  Implications  of  Tactical  TDMA  Waveform 


The  class  of  tactical  TDMA  waveforms  under  consideration  requires  certain  operations  in  hardware  which  are  not 
commonly  found  in  other  types  of  systems.  These  are  now  discussed  together  with  Hughes'  circuit  realizations. 

3.  1 Preamble  Acquisition 


Many  users,  constantly  in  motion,  report  Infrequently  in  a typical  TDMA  system.  One  consequence  is  that  the 
users  are  not  presynchronized  in  time  or  phase  to  the  arriving  signal  modulation.  The  waveform  organization  into 
regular  transmission  time  slots  can  be  maintained  by  relatively  unstable  (-1  part  in  10“®)  individual  user  clocks. 

Thus,  the  necessity  for  the  preamble  acquisition  function  in  a burst  TDMA  system  arises.  The  preamble  portion  of 
th-:  message  burst  is  used  to  ascertain  if,  and  precisely  when,  a burst  message  was  received.  In  addition,  as  the 
P_ftS  waveform  employs  coherent  data  detection,  an  initial  carrier  phase  estimated  accurate  to  within  ±45°  is  also 
derived  in  the  preamble  detection  circuitry. 

The  question  of  analog  vs  digital  implementation  of  the  preamble  correlator  is  interesting.  The  analog  approach 
is  theoretically  superior  in  additive  white  gaussian  noise  (AWGN),  although  a 2-blt/sample  digital  approach  causes  a 
basic  loss  in  AWGN  of  only  '0.6  dB.  The  analog  devices  (e.g. , SAW'S  and  CCD)  1)  are  more  difficult  to  make  pro- 
grammable, 2)  cannot  achieve  as  large  a time  bandwidth  (TW)  product  and  3)  are  more  temperature  sensitive.  On  the 
other  hand,  a digital  implementation  allows  for  ease  of  high  speed  programming,  large  TW  products,  and  wide  opera- 
tional temperature  ranges. 

Since  preamble  acquisition  detection  is  inherently  non-coherent,  chip  samples  must  be  taken  from  both  an  in- 
phase  (I)  and  a quadrature  (Q)  channel.  Hence,  with  2-bit  sampling,  four  sample  registers  and  a reference  register 
are  required  in  the  correlator  chip.  The  2-bit  samples  from  each  channel  are  compared  (correlated)  to  a reference 
pattern,  as  shown  in  Figure  8 for  the  PLRS  system.  The  individual  chip  comparisons  in  each  channel  are  coherently 
summed,  with  proper  weighting  to  the  least  and  most  significant  bits.  The  correlation  outputs  from  each  channel  are 
squared  and  then  summed  before  being  compared  to  the  threshold.  The  threshold  is  uniquely  determined  by  the  estab- 
lished probability  of  false  alarm  (PFA). 

3.  1.  1 Preamble  Correlator  Implementation 

The  PLRS  preamble  is  transmitted  at  a rate  of  5 megachips  per  second.  The  correlator  is  digital  2-bit/sample 
and  programmable  from  time  slot  to  time  slot.  Figure  9 presents  size  comparisons  that  show  the  extent  of  reductions 
that  have  taken  place.  The  engineering  development  model  (EDM)  breadboard,  occupying  the  right  half  of  the  figure, 
contains  10  CMOS  LSI  correlator  chips  shown  as  separate  circuit  components  on  the  board.  The  entire  breadboard 
has  been  reduced  to  a single  LSI  hybrid,  as  shown  in  the  upper  left.  This  hybrid  is  approximately  5 cm  long  and  con- 
sumes 220  mllliamps  at  12  volts  when  clocked  at  5 MHz.  In  the  lower  left  is  the  system  validation  model  (SVM)  bread- 
board, an  earlier  design  which  performed  the  same  function  (although  with  only  1 bit/sample). 

The  JTIDS  preamble  consists  of  32  frequency  hopped  segments,  each  32  chips  long  and  transmitted  on  a different 
frequency.  Since  the  chip  rate  is  the  same  in  JTIDS  and  PLRS  the  JTIDS  preamble  correlator  uses  the  same  CMOS 
LSI  correlator  chip  as  PLRS,  except  that  in  JTIDS  a different  TW  product  obtains. 
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Incidentally,  the  JTIDS  32  stage  correlator  chip  is  also  used  for  32-ary  signal  detection.  The  JTIDS  signalling 
format  is  basicall;’  32-ary  noncoherent  orthogonal  and  is  referred  to  as  cyclic  code  shift  keying  (CCSK)  because  each 
of  the  32  signals  Is  a cyclic  shift  of  a 32-chip  reference  pattern.  Therefore,  matched  filter  detection  of  the  informa- 
tion content  is  achieved  by  using  a single  digital  correlator  in  which  a 32-bit  reference  pattern  is  shifted  through  its 
32  possible  states.  The  largest  correlation  yields  the  maximum  likelihood  estimate  of  the  signal  transmitted.  However, 
if  none  of  the  correlations  is  sufficiently  large  an  erasure  is  declared  (the  symbol  will  hopefully  be  determined  by  the 
error  correction  code,  see  section  3.3). 

3. 2 Frequency  Synthesizer 

As  mentioned  previously,  frequency  hopped  TDMA  systems  require  frequency  agility  to  frustrate  both  interceptors 
and  jammers.  The  JTIDS  system  places  stringent  demands  on  the  agility  of  the  synthesizer,  for  in  JTIDS  the  frequency 
hop  takes  place  every  13  ps.  A description  of  the  JTIDS  frequency  synthesizer  follows. 

3.2.  1 The  JTIDS  Frequency  Synthesizer 

The  32  pulses  of  the  JTIDS  preamble  (each  pulse  6. 4 ps  long)  are  distributed  over  multiple  frequencies.  Be- 
cause, by  definition,  the  receiver  does  not  have  advance  knowledge  of  the  arrival  time  of  the  preamble  it  must  provide 
multiple  simultaneous  RF  channels  for  preamble  reception.  Once  synchronization  is  achieved  via  the  preamble  then 
one  frequency  hopped  RF  channel  is  sufficient.  Of  course,  only  one  frequency  hopped  channel  is  needed  for  transmis- 
sion of  an  entire  burst  message,  including  the  preamble. 

In  the  Hughes  Improved  Terminal  (HIT)  for  JTIDS  the  transmitter/receiver  (T/R)  is  designed  to  have  one  transmit 
channel  in  the  969-1206  MHz  frequency  band  and  multiple  receiver  channels  covering  the  band.  The  total  T/R  hardware 
consists  of  a Reference  Oscillator,  an  RF  Limiter,  an  Up-Down  Converter  module,  a Modulator  module,  an  Amplifier 
Switch  module,  and  four  Synthesizer/Detector  modules. 

Figure  10  is  a simplified  block  diagram  of  the  T/R.  The  RF  signal  designated  RCVR  INPUT  enters  the  T/R 
through  the  diode  limiter.  Here,  the  signal  is  power  limited  to  less  than  50  mW  in  order  to  avoid  damaging  the  low 
noise  front  end  amplifier  in  the  down-converter.  The  first  mixer  translates  the  Tacan  band  frequency  of  969-1206  MHz 
to  a 369-606  MHz  IF.  This  first  IF  signal  drives  the  receiver-detector  channels.  Each  of  the  receiver- 
detector  channels  has  its  own  synthesized  local  oscillator  (LO)  which  translates  the  first  IF  signal  to  a second  IF  at 
315  MHz.  This  signal  passes  through  a surface  acoustic  wave  (SAW)  matched  filter  and  is  translated  to  a base-band 
frequency  of  1. 25  MHz  by  mixing  it  with  a 3rd  LO  of  313.  75  MHz  in  the  I and  Q phase  detectors.  The  I and  Q signals 
are  sampled  and  converted  to  the  four  digital  signals  shown  in  Figure  10  at  the  output  of  the  comparator,  which  are 
then  sent  to  the  signal  processor.  In  the  data  mode,  only  one  detector  channel  is  used,  and  the  remaining  program- 
mable synthesizers  are  time  shared  (carouseled)  to  provide  the  LO  signal.  Thus  the  required  settling  time  per  synthe- 
sizer is  4 x 13  52  ps. 

The  synthesizer  is  capable  of  generating  all  the  first  LO  frequencies  from  684  to  921  MHz  in  uniform  steps.  It  is 
designed  to  change  frequency  and  be  stable  in  less  than  the  required  52  ps.  During  the  preamble  mode,  each  of  the 
synthesizers  is  set  to  a particular  frequency  for  that  channel  well  in  advance  of  the  time  slot.  Each  synthesizer  fre- 
quency is  fixed  for  the  duration  of  the  preamble.  However,  during  the  data  mode  of  the  receiver,  the  LO  frequency 
must  change  for  every  time  segment  (i.e. , pulse)  of  the  received  waveform.  Thus,  four  synthesizers  are  used  to 
support  a data  channel.  Each  synthesizer  is  set-up  ahead  of  the  scheduled  time  usage  and  is  then  carouseled  to  the 
receiver  down-converter  via  a single-pole  4-throw  switch  in  the  amplifier  switch  assembly. 

The  Synthesizer/Detector  assembly  consists  of  two  identical  receiver  channels  and  two  identical  LO  frequency 
synthesizers,  both  receiver  and  synthesizer  channels  are  identical.  In  order  to  minimize  cross  talk  between  chan- 
nels, each  synthesizer  is  packaged  in  its  own  cavity  and  separated  from  the  cavity  which  houses  the  two  receiver 
channels.  A photograph  of  the  assembly  is  shown  in  Figure  11. 

The  synthesizer  circuit  can  be  divided  into  four  major  functional  areas.  The  first  is  the  "frequency  word  memory 
circuit'  which  converts  the  serial  frequency  word  input  into  a parallel  word  output  which  sets  the  divide-by-n  ratio  of 
the  phase  lock  loop.  The  second  is  the  "presen.  circuit"  which  gets  its  input  from  the  frequency  word  memory  circuit 
and  applies  a dc  voltage  to  coarse-tune  the  voltage  controlled  oscillator  (VCO)  close  to  its  desired  output  frequency. 

The  third  is  the  "phase  locked  circuit"  which  generates  a dc  voltage  to  fine  tune  the  VCO  to  the  exact  frequency  of  n 
times  the  1.5-MHz  input  reference  frequency.  (The  frequency  word  selects  the  absolute  value  of  n and  thus  the  output 
frequency.  The  phase  detector  and  the  loop  filter  are  part  of  the  feedback  circuit  to  maintain  coherence  between  the 
output  frequency  and  the  input  reference.)  The  fourth  is  the  VCO  which  is  a thin-film  hybrid  tunable  over  the  342  to 
461  MHz  band.  The  oscillator  frequency  is  doubled  inside  the  hybrid  to  generate  the  684-921  MHz  LO  output. 

The  synthesizer/detector  module  utilizes  state-of-the-art  technology  in  both  the  circuit  design  and  the  packaging. 
The  VCO  in  the  synthesizer  Is  a thin-film  design  due  to  the  high  frequency  and  broad  bandwidth  requirements.  The 
thin-film  technique  is  repeatable  from  unit  to  unit  and  hence  is  suitable  for  production  in  large  quantities. 

3.2.2  The  Surface  Acoustic  Wave  (SAW)  Oscillator 

A unique  application  of  surface  acoustic  wave  (SAW)  technology  is  found  in  the  modulator  assembly. 

The  modulator  generates  a low  frequency  reference  signal  of  1.5  MHz  and  a 40-Mliz  clock  signal  using  transistor 
multipliers  and  IC  dividers.  It  also  generates  a phase-locked  1.  25-MHz  internal  reference  for  its  two  phase-locked 
loops.  One  of  the  phase-locked  loops  generates  a 313.  75-MHz  signal  for  use  as  the  receiver  phase  detector  LO.  The 
feedback  and  phase  detector  circuits  of  the  phase-locked  loop  are  a very  straightforward  design  while  the  SAW  VCO 
is  a novel  design  with  a new  technology.  The  SAW  device  is  a time  delay  element  with  a narrow  frequency  band-pass 
characteristic  at  a UHF  frequency.  When  the  SAW  device  is  connected  in  series  within  the  feedback  path  of  an  oscil- 
lator, an  oscillation  will  occur  at  the  frequency  of  the  narrow  SAW  band-pass.  In  addition,  if  a voltage  controllable 
phase  shifter  is  added  to  the  same  path,  the  oscillator  frequency  can  be  shifted  and  hence  phase-locked  to  a harmonic 
of  the  1.  25-MHz  reference  signal.  The  advantage  of  using  the  SAW  device  at  313.  75  MHz  is  that  this  technique 
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eliminates  a frequency  multiplier  which  would  have  to  be  used  with  a low  frequency  voltage-controlled  crystal  oscillator 
to  generate  a LO  signal  with  the  required  frequency  and  stability.  Figure  12  is  a photograph  of  the  SAW  device. 

3.  3 Error  Control  Coding 

Digital  messages  of  the  sort  being  transmitted  in  TDMA  systems  require  extremely  low  probability  of  incorrect 
message  acceptance,  PfMA*  Typical  messages  might  be  1)  command  messages  that  modify  operation  of  units  (e.  g. , 
time  slot  assignment),  2)  time  of  day  messages  for  synch,  3)  position  reports,  4)  status  reports,  5)  time  of 
arrival  measurement  reports  for  the  position  location  function.  To  guard  against  the  acceptance  of  incorrect  messages, 
the  data  are  first  encoded  purely  for  error  detection.  Before  the  receiver  releases  any  message,  that  message  is 
validated  by  checking  the  consistency  of  the  received  data  and  parity  check  bits.  This  message  validation  and  the  user 
address  check  maintains  a verly  low  PfMA* 

In  addition,  error  correcting  codes  are  frequently  utilized  in  TDMA  waveforms  for  enhanced  signal  to  noise  and 
anti-jam  (AJ)  performance.  Both  convolutional  and  block  codes  have  been  employed  in  the  past.  Both  the  PLRS  and 
JTIDS  waveforms  employ  message  validation  coding  and  interleaved  error  correction  coding. 

1 

3.3.1  Error  Detection/Correction  Hardware 

The  error  control  coding  for  the  PLRS  waveform  is  based  on  an  error  correction  Hamming  code  and  a shortened 
cyclic  code  used  for  message  validation.  The  necessity  of  minimizing  the  size,  power  and  weight  of  the  PLRS  manpack 
unit  was  the  principal  reason  for  selection  of  a simple  and  not  very  powerful  code.  In  fact,  the  SVM  phase  waveform 
was  uncoded,  but  interference  from  friendly  radars  caused  appreciable  message  loss.  Hence,  the  interleaved  coded 
waveform  provides  for  operation  with  ~10  high  power  radars  while  also  providing  increased  protection  from  pulse 
jammers.  Each  PLRS  burst  message,  Figure  13,  consists  of  information  bits  and  message  validation  bits  which  are 
encoded  as  code  words.  The  breadboard  message  validation  encoder/decoder  and  its  equivalent  CMOS  LSI  are  shown 
in  Figure  14.  The  LSI  circuit  consumes  only  10  milliwatts  at  5.2  volts  when  clocked  at  1.25  MHz.  The  error  encoding/ 
correction  and  interleaving/deinterleaving  function  has  also  been  implemented  with  custom  CMOS  LSI  as  shown  in 
Figure  15.  This  device  dissipates  less  than  5 milliwatts  are  5.2  volts.  Note  that  in  a TDMA  system  these  devices 
arc  not  constantly  in  use,  and  that  the  standby  power  of  CMOS  devices  is  virtually  negligible.  Therefore,  the  total 
energy  drain  (e.g. , from  batteries)  by  these  devices  can  be  kept  very  small. 

The  JTIDS  architecture  provides  for  both  uncoded  and  coded  transmissions.  The  error  correction  coded  JTIDS 
waveform  is  based  on  the  powerful  (31,15)  Reed-Solomon  code. 

Figure  16  shows  the  format  used  for  transmitting  the  Reed-Solomon  error  correction  coded  message.  There  are 
three  (31,15)  Reed-Solomon  code  words  and  a special  (16,4)  Reed-Solomon  Header.  The  (31,15)  words  contain  31 
five-bit  symbols  (155  bits)  of  which  15  are  five-bit  information  symbols  (75  bits).  This  leaves  16  five-bit  parity  sym- 
bols to  be  used  for  error  correction.  Each  (31, 15)  code  word  can  correct  up  to  eight  symbol  errors,  or  up  to  16  era- 
sures (no  decision  on  which  symbol  was  transmitted)  or  any  combination  of  errors  and  erasures  in  which: 

2 x (number  of  errors)  + (number  of  erasures)  < 16. 

To  Insure  that  pulsed  interference  does  not  saturate  the  error  correcting  capability  of  any  single  Reed-Solomon 
code  word,  the  symbols  are  not  transmitted  in  order,  but  the  order  is  permuted  over  the  109-symbol  message  by  a 
fixed  permutation  pattern.  The  Inverse  operation  is  supplied  at  the  receiver  before  decoding  operations. 

In  addition  to  the  error  correction  capability  of  coded  messages,  a special  error  detection  code  is  added  to  all 
formatted  messages.  This  code  supplies  12  parity  bits  designed  to  trap  any  messages  containing  errors  missed  by 
the  Reed-Solomon  decoding  operation.  This  code  reduces  the  probability  that  a formatted  message  contains  undetected 
errors  to  a very  low  PfMA- 

The  (16,4)  Reed-Solomon  Header  is  used  in  both  coded  and  uncoded  messages.  In  formatted  messages  it  contains 
Information  about  the  message  type  and  the  12-error  detection  code  parity  bits.  In  free  text  messages,  it  contains 
message  type  data  and  a 16-blt  code  identifying  the  transmitting  terminal. 

The  present  Implementation  of  the  RS  decoder  takes  4 cards  of  ~50  MSI  devices  each  and  consumes  22  watts  of 
power  at  5 volts.  The  unit  can  decode  a (31,  15)  RS  code-word  in  650  ps,  worst  case.  An  ongoing  IR&D  effort  will 
reduce  the  size  and  power  of  the  decoder  to  1/2  card  and  5. 0 watts.  The  new  design  is  being  implemented  with  I2L 
LSI. 


Even  though  the  TDMA  system  bandwidth  is  intentionally  made  very  wide  by  spread  spectrum  signaling  there  are 
stringent  controls  on  the  radiated  spectrum.  These  controls  take  the  form  of  specifications  on  the  "instantaneous" 
power  spectral  density,  the  spectrum  that  is  observed  while  the  transmitter  is  dwelling  on  one  of  the  available  fre- 
quencies in  the  frequency-hopped  bandwidth.  The  instantaneous  spectrum  is  generated  by  the  direct  modulation  of  the 
PN  chip  stream  on  the  carrier.  In  the  PLRS  and  JTIDS  systems,  as  mentioned  previously,  the  modulation  is  at  5 mega- 
chips  per  second.  Figure  17  shows  the  typical  JTIDS  spectrum  centered,  in  this  instance,  on  an  RF  carrier  at  969  MHz. 
It  is  produced  by  a filtered  form  of  the  commonly  known  Minimum  Shift  Keying  (MSK)  modulation  method  [Amoroso  and 
Kivett,  1977,  Amoroso,  1976]  and  presents  greatly  reduced  spectral  sidelobes  in  conformity  with  a stringent  specifi- 
cation. At  Hughes  the  filtered  version  of  MSK  is  called  CPSM  (continuous  phase  shift  modulation).  The  spectrum 
shown  was  measured  at  the  output  of  the  RF  power  amplifier  driven  into  saturation. 


The  unique  spectrum  realization  requirement  in  a frequency  hopped  TDMA  system,  a requirement  met  in  PLRS 
and  JTIDS,  is  to  produce  an  acceptable  spectrum  without  the  use  of  an  RF  filter  following  the  power  amplifier  stage. 
Clearly  no  fixed  RF  filter  is  appropriate  since  the  RF  carrier  is,  by  design,  frequently  changing.  Neither  is  it  tech- 
nologically feasible  to  "hop"  an  RF  filter  to  follow  the  carrier.  A further  complication  enters  from  the  need  to  have 


a prime  power  efficient  RF  output  stage.  High  prime  power  efficiency  usually  means  an  amplifier  driven  to  saturation, 
such  as  a class  C amplifier.  In  other  words  the  radiated  signal  should  have  a constant  carrier  envelope.  The  litera- 
ture Is  replete  with  methods  for  synthesizing  and  filtering  data  signals  to  produce  excellent  spectra,  but  by  and  large 
these  methods  lead  to  non-constant  carrier  envelopes.  MSK  modulation  Is  remarkable  for  its  production  of  a constant 
envelope  signal  with  relatively  small  spectral  sidelobes.  The  circuit  techniques  for  realizing  MSK  have  been  some- 
what cumbersome  in  the  past.  Hughes  has  Improved  considerably  on  them  for  PLRS  and  JTIDS. 

Figure  18  shows  an  early  Hughes  circuit  used  In  the  Wideband  Command  and  Control  Modem  (WCCM),  to  generate 
CPSM  at  60  Megachip.  This  circuit  was  about  as  complex  as  those  reported  by  other  Investigators  [Mathwich  et  al. , 
1974],  One  disadvantage  of  this  circuit  was  the  size  and  cost  of  Its  large  number  of  components:  four  mixers,  two 
narrowband  filters,  two  delay  flip  flops,  circuits  for  dividing  by  two  and  four,  an  adder  and  a square  wave  clock  sep- 
arate from  the  Incoming  bit  stream.  Perhaps  a more  fundamental  difficulty  was  the  need  to  keep  all  the  components 
precisely  time-aligned  to  within  a fraction  of  a period  of  the  IF  oscillator. 

The  current  Hughes  modulator  for  both  PLRS  and  JTIDS,  strikingly  simple,  is  shown  in  Figure  19.  The  basic 
operation  of  this  circuit  has  been  adequately  explained  [Amoroso  and  Kivett,  1977].  The  h(t)  filter,  realized  as  a 
single  SAW  device,  Incorporates  additional  filtering  necessary  to  reduce  spectral  sidelobes  much  below  those  commonly 
found  In  MSK,  thus  producing  CPSM.  Figure  20  gives  a schematic  representation  of  the  SAW  device,  which  is  passive 
and  time-invariant.  It  exploits  the  design  versatility  of  interdigital  transducers  to  achieve  the  desired  spectral  side- 
lobes. The  frequency  response  of  the  input  transducer  is  trapezoidal  shaped  to  pass  the  main  lobe  of  the  spectrum 
virtually  undisiorted  while  suppressing  sidelobes.  The  modulation  is  performed  at  IF,  ultimately  leading  to  the  spec- 
trum of  Figure  17. 

As  described  previously  [Amoroso  and  Kivett,  1977],  an  equally  simple  demodulator  circuit  recovers  the  chip 
stream  at  the  receiver.  A SAW  matched  filter  appears  there  to  gain  the  usual  performance  advantages  in  noise.  Fig- 
ure 21  shows  a photograph  of  the  complete  modulator  and  receiver  matched  filter. 

Research  continues  at  Hughes  to  improve  the  spectrum  without  sacrificing  the  circuit  simplicity. 

3.  5 Network  Management  in  the  Tactical  TDMA  System 

The  PLRS  and  JTIDS  systems  use  contrasting  modes  of  network  management,  with  corresponding  differences  in 
hardware  configurations.  The  JTIDS  system  is  "distributed,  " i.  e. , there  is  no  master  unit  which  assumes  the  func- 
tion of  structuring  the  network.  PLRS  is  centrally  managed,  with  a large  share  of  the  computing  for  all  user  units 
being  performed  at  the  master  unit.  One  consequence  is  that  the  PLRS  user  units  have  been  reduced  to  manpack  size, 
in  comparison  with  the  larger  units  of  JTIDS  (more  detailed  size  comparison  will  be  given  later).  A discussion  of  the 
PLRS  network  functions  follows. 

3. 5. 1 Network  Functions  in  the  PLRS  System 

PLRS  functions  in  a dispersed,  mobile,  primarily  ground  environment.  A complex  management  function  has 
evolved  out  of  the  need  to  maintain  continuous  reports  from  hundreds  of  units  while  many  of  the  units,  being  In  motion, 
acquire  (and  lose)  radio  line  of  sight  to  other  units  over  sometimes  irregular  terrain.  The  maintenance  of  communi- 
cations link  assignments  among  UUs  is  a critical  management  function  of  the  MU,  for  most  UUs  depend  on  the  integral 
relay  capability  of  other  UUs  to  provide  a communications  path  back  to  the  MU.  A single  PLRS  network  can  consist  of 
several  Master  Units  (MUs),  each  with  a community  of  a few  hundred  user  units  (UUs).  All  of  these  units  operate  in  a 
synchronous  time-frequency  structure  such  that  no  significant  mutual  Interference  results.  All  data  is  transferred 
with  cryptographic  security  and  privacy  under  MU  control. 

Network  management  within  PLRS  Involves  several  aspects  of  system  design,  network  architecture,  allocation  of 
time-frequency  resource  to  the  MUs,  assignment  of  resource  to  the  UUs,  and  division  of  responsibilities  between  the 
MUs  and  UUs.  Because  of  the  emphasis  on  minimum  size  and  cost  of  the  UU  and  on  operation  of  the  UUs  by  personnel 
with  very  little  training,  the  more  complex  functions  are  performed  at  the  MU  where  practical. 

PLRS  uses  the  concept  of  transaction  groups,  rather  than  Individual  time  slots,  for  assignment  of  resource  and 
functions  to  the  UU.  Using  this  approach  a repetitively  timed  loop  of  up  to  16  time  slot  assignments  can  be  made  with  a 
single  command  from  the  MU  to  a UU. 

The  UU  has  several  responsibilities  relative  to  network  management.  The  UUs  obtain  coarse  (±100  usee)  timing 
from  the  MU  or  other  UU  over  up  to  four  levels  of  relay.  They  demand  access  for  network  entry  or  data,  and  they 
monitor  for  commands  or  data  addressed  to  themselves.  Once  active  network  entry  has  been  achieved  the  UUs  rou- 
tinely report  data  to  the  MU  consisting  of  time  of  arrival  and  barometric  measurements,  communicant  IDs,  access 
demands,  and  intercommunity  contacts.  UUs  also  perform  assigned  relay  functions  including  intercommunity  data 
delivery. 

The  MU  has  the  major  responsibility  for  network  management.-  These  responsibilities  include  message  traffic 
control,  reporting  and  performance  monitoring,  in  addition  to  the  basic  function  of  assigning  relay  paths  and  cross- 
links. Message  traffic  control  consists  of  reviewing  the  current  message  (data  and  command)  distribution  require- 
ments In  conjunction  with  the  available  relay  paths  and  scheduling  traffic  based  on  priorities.  Reporting  consists  of 
reviewing  all  of  the  data  requests  for  availability  and  authorization  and  then  queuing  requests  and  data  messages.  Re- 
porting also  formats  data  messages  both  for  delivery  over  the  PLRS  network  and  to  an  interface  control  function  for 
data  exchange  with  command  and  control  centers.  Of  course  the  key  function  of  network  management  is  link  assign- 
ment. Network  management  reviews  the  current  network  link  assignments,  link  reliabilities  and  desired  reporting 
rates  to  build  and  optimize  the  network  assignments  to  the  UUs. 

3. 5.1.1  The  PLRS  Master  Unit  Processors  and  Peripherals 

The  MU  processors  and  peripherals  occupy  the  better  part  of  an  S-280  equipment  shelter,  which  also  houses  the 
MU  operator.  The  volume  is  614  cubic  feet. 


The  processing  requirements  of  the  MU  dictate  that  the  computation  subsystem  include  an  AN/UYK-7  and  two 
AN/UYK-20  processors.  The  allocation  of  tasks  to  these  computers  is,  in  general,  as  follows:  The  network  control 
task  to  one  AN/UYK-20;  tracking,  filtering  and  simulation  tasks  to  the  AN/UYK-7;  and  display  control  and  remote 
Input/output  (I/O)  handling  tasks  to  the  AN/UYK-20  (see  Figure  22).  These  processors  were  selected  because  of  their 
applicability  to  real-time  and  data  handling  problems,  their  advanced  design,  their  existence  in  the  Government  inven- 
tory, and  their  basic  compatibility. 

Both  of  the  selected  processor  types  are  highly  reliable,  ruggedized  computers  with  versatile  functional  architec- 
tures. These  units  are  designed  to  operate  in  the  hostile  ship  and  shore  environments  characteristic  of  the  operational 
environment  in  which  PLRS  will  be  deployed. 

The  AN/UYK-7  computer  is  available  in  either  single  or  multiple  processor  configuration  with  capabilities  up  to 
48K  words  of  memory  and  16  input/output  channels  per  cabinet.  The  single-bay  configuration,  with  48K  words  of  mem- 
ory and  four  I/O  channel  groups,  has  been  selected  as  appropriate  for  the  time  of  arrival  (TOA)  processor.  Two  of 
the  I/O  channels  of  the  AN/UYK-7  will  be  assigned  to  the  interfacing  AN/UYK-20  processors. 

The  AN/UYK-20  computer  Is  a highly  efficient  processor  well  suited  for  real-time  communications  and  display 
controlling  applications  of  the  type  found  in  the  MU. 

Network  Control  Processor  - The  AN/UYK-20  I/O  channel  set  is  configured  with  both  Naval  Tactical  Data  System 
(NTDS)  parallel  and  NTDS  serial  channels  to  support  the  Interface  requirements  of  the  system.  The  processor  com- 
municates with  the  Command  Response  unit,  the  TOA  AN/UYK-7,  the  keyboard  printer,  one  channel  of  the  tape  unit, 
and  the  display  processor  using  parallel  formatted  charnels.  The  AN/UYK-7  and  inter-AN/UYK-20  channels  are 
equipped  for  32-bit  word  transfers  in  order  to  support  the  anticipated  message  flow.  An  NTDS  serial  interface 
(10  Mb/s)  is  provided  for  communicating  with  an  external  source  of  data  from  either  another  MU  in  a driver  mode  or 
the  Command  and  Control  Center. 

Display  Processor  — The  display  processor  AN/UYK-20  also  has  its  I/O  channel  set  configured  in  both  serial  and 
parallel  channels.  TEe  parallel  channels  communicate  with  the  second  channel  of  the  tape  unit,  the  AN/UYK-7,  and 
the  network  control  processor.  The  serial  channels  are  used  with  the  display  and  control  station  and  the  external  con- 
nection for  remoting  the  display,  operating  with  a secondary  display  station,  providing  the  real  time  PLRS  (RTPLRS) 
driver  data  to  an  MU,  or  communicating  with  the  Command  and  Control  Center.  These  external  serial  channels  pro- 
vide for  communications  up  to  500  feet  using  the  pair  of  coaxial  cables  furnished  with  the  MU. 

MU  Peripherals  - A minimal  set  of  peripheral  devices  is  required  to  support  the  MU  processing  subsystem.  This 
set  includes  a cartridge  magnetic  tape  unit  and  an  I/O  terminal  which  consists  of  a keyboard  and  a page  printer.  These 
peripherals  are  connected  to  the  AN/UYK-20  processors  through  standard  NTDS  I/O  channel  interfaces. 

The  cartridge  magnetic  tape  unit  (CMTU)  Is  a militarized  unit  nomenclatured  the  AN/USH-26  (V).  This  variable 
configuration  device  is  a member  of  the  standard  AN/UYK-(  ) peripheral  set  and  can  be  equipped  with  from  one  to 
four  cartridge  tape  drives.  The  unit  requires  four  drives  for  the  MU  application  to  support  program  loading,  map 
handling,  UU  library  tapes,  and  data  logging/ recording.  A typical  application  would  find  the  library  tape,  the  map 
tape,  and  two  logging  tapes  in  place.  During  program  load,  the  map  tape  might  be  displaced. 

This  four-drive  system  provides  a high  degree  of  flexibility  and  the  capability  to  operate  with  little  or  no  loss  in 
performance  in  the  event  of  the  failure  of  a drive  unit.  The  cartridges  are  standard  3M  DC300A  units  which  provide 
up  to  2.  9 million  bytes  of  data  storage.  The  cartridges  are  considerably  easier  to  handle  and  store  than  are  tape  reels. 

The  tape  unit  Includes  a two-channel  multiplex  capability  which  allows  either  of  the  two  AN/UYK-20  processors 
access  to  any  of  the  tape  drives.  This  feature  provides  an  efficient  handling  of  data  transfers  without  burdening  the 
AN/UYK-7  with  an  I/O  handling  task. 

The  second  unit  in  the  peripheral  set  is  the  keyboard/page  printer  terminal.  This  militarized  unit  serves  as  an 
operator's  manual  terminal  for  processor  control,  message  input/output,  and  listing/status  printout.  An  important 
secondary  function  of  this  equipment  is  to  act  as  a back-uD  for  the  system  control  capability  normally  provided  by  the 
keybo-  1 1 of  the  display  and  control  station.  Because  of  this  back-up  role,  the  terminal  is  connected  to  the  network 
processor  rather  than  to  the  display  processor. 

J 

3. 5. 1,2  The  PLRS  User  Unit 

The  PLRS  UU,  shown  physically  in  Figure  23,  is  a self-contained  manpack  occupying  a volume  of  0.29  cubic 
feet.  Only  through  the  extensive  use  of  circuit  miniaturization,  in  particular  large  scale  integration  (LSI),  has  this 
small  size  been  attained.  A total  of  16  custom  LSI  chips  are  used  in  addition  to  the  preamble  correlator  chips  dis- 
cussed in  section  3.1.1  above.  Their  distribution  in  the  user  unit  is  stated  in  connection  with  specific  functions  below. 

A functional  block  diagram  of  the  PLRS  basic  User  Unit  (UU)  is  presented  in  Figure  24.  Operation  of  the  UU  can 
be  explained  in  terms  of  the  processing  done  by  each  functional  module.  Most  of  the  functions  shown  in  the  figure  are 
not  specifically  separable  into  corresponding  physical  modules. 

The  following  discussion  of  each  UU  function  describes  the  processing  aspects  of  the  UU. 

RF/IF  Function  - The  PLRS  RF/IF  function  performs  frequency  conversion,  amplification,  and  filtering  of  the 
transmuted  and  received  signals.  During  receive,  this  function  also  performs  A/D  conversion  of  the  incoming  sig- 
nals in  a 2-bit  adaptive  A/D  converter,  for  subsequent  digital  processing  by  the  Signal  Processor  Function  (SP).  Dur- 
ing transmit,  the  digital  output  of  the  SP  is  used  to  generate  the  PLRS  CPSM  modulation  in  the  RF/IF  function.  The 
UU  crystal  oscillator  time  base,  frequency  hopped  synthesizer,  and  local  oscillators  are  all  contained  in  the  RF/IF 
function. 

Signal  Processor  Function  — The  Signal  Processor  function  performs  preamble  detection/generation,  interleaving/ 
deinterleaving  and  error  correction/error  detection  encoding/decoding  of  received  and  transmitted  signals,  PN  gener- 
ation, data  correlation,  time  and  phase  detection/correction,  TOA  measurement  and  other  functions  required  to 
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digitally  process  PLRS  signals.  The  SP  interfaces  with  the  RF/IF  function  and  the  Secure  Data  Unit  function  (SDU). 
This  function  uses  the  preamble  detection  LSI  plus  3 data  correlator  LSI  chips. 

Secure  Data  Unit  Function  — The  Secure  Data  Unit  tunctlon  encrypts/decrypts  transmitted  and  received  PLRS  sig- 
nals,  provides  message  validation  encoding/decoding  and  alarm  checking,  and  provides  data  for  control  of  the  PN  gen- 
erator, frequency  hopping,  and  time  scrambling.  This  function  uses  3 of  the  LSI  chips. 

Message  Processor  Function  — The  Message  Processor  function  (MP)  contains  a CMOS  microprocessor  that  is 
the  "brain"  of  the  User  Unit.  THs  function  controls  and  time-sequences  (along  with  the  Timing  and  Control  function 
(T&C)  working  as  a slave)  all  other  processes  done  within  the  User  Unit.  The  MP,  additionally,  generates,  checks, 
composes,  decodes,  Interprets  and  reacts  to  the  PLRS  link  message  set.  The  MP's  microprocessor  accomplishes 
most  of  the  processing  done  by  this  function.  A set  of  programs  will  be  stored  in  each  UU  in  the  form  of  firmware. 
Each  one  of  these  programs  will  direct  the  UU  to  conduct  a large  number  of  sequential  operations  (i.  e. , receive, 
measure,  record,  transmit,  store,  receive,  combine,  transmit,  etc. ) over  and  over  again.  Thus  the  MU  has  the 
ability  to  place  a UU  in  one  of  many  modes  to  accomplish  its  required  processing.  The  MP  also  interfaces  with  the 
Data  I/O  device,  which  could  be  a User  Readout,  Pilot  Control  Display  Panel,  or  Special  Data  Module.  This  function 
uses  8 of  the  LSI  nips. 

Operator/Control  Panel  Function  - The  Operator/ Control  Panel  function  accomplishes  the  User-Unlt-to-human- 
operator  Interface  required  to  enable  power,  load  cryptovariables,  monitor  operation  of  the  UU,  and  interface  with 
the  antenna  and  Data  I/O  device. 

Barometric  Transducer  Function  — The  Barometric  Transducer  function  enables  the  UU  to  make  measurements  of 
barometric  pressure  and  report  this  data  to  the  MU,  where  it  is  converted  to  altitude  information. 

Timing  and  Control  Function  — The  Timing  and  Control  function  generates  all  time  slot  timing  signals  used  within 
the  UlL  Additionally,  the  T&C  function  generates  all  the  sub-time  slot  signals,  and  the  enable  ar.o  disable  control 
signals  required  by  the  UU,  as  commanded  by  the  MP  function. 

Power  Distribution  Function  - The  Power  Distribution  function  contains  the  power  supplies,  regulators,  power 
line  filters  and  power  switching  (and  sequencing)  circuitry  needed  by  the  UU.  This  function  is  controlled  by  the  T&C 
and  operator/ control  panel  functions  and  provides  power  to  all  the  electronics  within  the  UU. 

The  input/output  device,  not  properly  part  of  the  basic  user  unit.  Incorporates  2 of  the  LSI  chips. 

4.  0 Unit  Volume  and  Power  Comparisons 

Contrasts  in  overall  size  and  power  consumption  of  the  PLRS  and  JTIDS  units  will  be  seen  to  reflect  the  differ- 
ences in  system  requirements  that  have  already  been  discussed.  Figure  25  presents  a summary  of  the  volume,  in 
cubic  feet,  and  average  power  consumption,  in  Watts,  of  three  types  of  units,  (1)  the  JTIDS  terminals  for  the  Boeing 
E-3A  program,  (2)  the  JTIDS  Hughes  Improved  Terminal  (HIT)  under  development  for  fighter  aircraft,  (3)  the  PLRS 
user  unit.  The  circles  in  the  diagram  should  be  regarded  as  cross-sections  of  spheres  whose  volumes  are  correctly 
proportioned  to  represent  volume  or  power. 

The  large  volume  of  the  JTIDS  high  power  terminal  for  E-3A  was  allowed  to  permit  a minimum  technical  and 
schedule  risk  development.  The  terminal  Is  designed  to  provide  functional  modularity  and  is  packaged  in  ATR  boxes 
for  airborne  application.  Now  that  the  JTIDS  terminals  have  been  built,  tested,  and  found  to  perform  to  specifi- 
cation, attention  is  being  turned  to  size  and  cost  reduction.  Hughes  has  already  developed  and  is  under  Air  Force  con- 
tract to  deliver  a new  miniaturized  design  which  provides  the  full  capabilities  of  the  E-3A  terminal  and  is  suitable  for 
some  fighter  installations.  Technology  for  this  Hughes  Improved  Terminal  (HIT)  was  discussed  in  Section  3.2  above. 

Hughes  is  further  reducing  the  size  and  cost  of  HIT  by  applying  LSI  and  other  miniaturization  technologies  to  pro- 
duce a simplified  terminal  for  widespread  fighter  applications.  The  JTIDS  Fighter  Terminal  will  be  reduced  to  the 
size  and  power  levels  shown  in  the  second  row  of  Figure  25. 

The  third  row  in  Figure  25  represents  the  PLRS  user  unit.  Its  small  size  and  power,  even  in  comparison  to  the 
JTIDS  Fighter  Terminal,  owes  largely  to  the  assignment  of  many  of  the  computational  functions  to  the  master  unit, 
as  discussed  previously.  A second  important  factor  is  the  relatively  low  frequency  of  message  transmission  and 
reception  in  PLRS  vs.  JTIDS. 

Note  that  a large  share  of  the  volume  and  power  in  all  3 units  is  devoted  to  communications  processing  and  signal 
processing  (or  signal  and  message  processing).  Now  the  JTIDS  message  transmission  and  reception  load  is  much 
heavier  than  in  PLRS.  In  particular,  the  JTIDS  transmitter  must  be  prepared  to  transmit  in  900  consecutive  time 
slots  of  the  total  of  1536  time  slots  in  one  12-second  cycle.  PLRS,  benefltting  from  the  transaction  group  structure 
of  time  slots  and  a generally  smaller  work  load,  never  requires  a user  unit  to  transmit  more  than  once  per  12  time 
slots,  or  receive  a message  more  than  every  32  time  slots.  From  this  comparison  the  heavier  communications  em- 
phasis of  JTIDS  is  evident.  The  JTIDS  links  can  support  digitized  voice  transmission,  whereas  PLRS  obviously  trans- 
fers relatively  small  amounts  of  data.  In  fact,  the  reporting  and  reception  rates  in  PLRS  are  geared  primarily  to 
precise  position  location. 

The  small  computational  load  in  PLRS  is  distributed  in  time,  so  that  computing  can  be  performed  by  relatively 
slow  circuits  that  consume  small  amounts  of  power.  Even  the  peak  demands  on  the  power  converter  are  reduced  by 
the  inclusion  of  a 6800-pf  capacitor  to  store  energy  for  the  transmission  burst. 

In  modem  TDMA  systems  the  interplay  of  system  architecture,  wav?form  design,  and  hardware  technology  poses 
some  very  complex  challenges  which  arc  new  to  the  field  of  tactical  radio  signalling.  Hughes,  in  PLRS  and  JTIDS, 
continues  to  demonstrate  that  systems  can  evolve  to  meet  specific  functional  requirements  within  the  tactical  hardware 
size,  weight,  and  power  constraints. 
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Fig.4  The  cyclic  timing  structure  of  a TDMA  network 
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Fig.6  The  time  divisions  of  JTIDS 
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Fig.  1 1 JTIDS  synthesizer  detector 
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Fig.  1 3 PLRS  burst  waveform  structure 


Fig.  14  PLRS  message  validation  circuit  miniaturization 
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Fig.  1 7 Instantaneous  transmitted  spectrum  for  JTIDS 
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Fig.  1 8 Early  modulator  circuit  for  CPSM 
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Fig.  1 9 Simplified  modulator  circuit  for  CPSM 
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Fig.20  Schematic  of  SAW  device  for  CPSM  modulation 
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Fig.22  PLRS  master  unit  peripheral  interconnect  block  diagram 


Fig.24  PLRS  basic  user 
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DISCUSSION 


M.G.Stainsby 

How  are  time  slots  allocated  in  JTIDS  and  PLRS? 

Authors’  Reply 

In  the  PLRS  system,  each  frame  is  comprised  of  eight  time-interleaved  transaction  groups,  consisting  of  16  time 
slots  each.  This  provides  for  structured  information  transfer  between  the  master  unit  and  sets  of  four  user  units, 
while  providing  adequate  time  between  successive  transmissions  by  a single  user  unit.  Once  a user  unit  has  been 
assigned  its  user  level,  the  user  unit  knows  exactly  when  to  transmit,  when  to  receive,  what  processing  is  required 
and  when  to  perform  the  processing.  The  transaction  group  structure  also  improv  s.  lobabilities  for  receiving  both 
outbound  and  inbound  message  traffic.  In  JTIDS  the  1536  time  slots  in  each  cycle  are  divided  into  3 interleaved 
sets  of  512  slots  each,  as  shown  in  Figure  6 of  the  text.  Each  epoch  contains  512  x 64  = 32768  = 2,s  time  slots  of 
each  set.  Time  slot  assignments  for  transmission  are  generally  made  on  the  basis  of  2N  time  slots  per  epoch  where 
N can  vary  from  0 to  15. 

M.G.Stansby 

How  do  the  systems  ensure  that  no  two  users  use  a time  slot  simultaneously? 

Authors’  Reply 

In  both  the  PLRS  and  JTIDS  systems  the  usual  network  disciplines  of  a TDMA  system  apply.  All  users  enjoy  the 
exclusive  use  of  time  slots  assigned  to  them.  The  one  possible  exception  is  during  net  entry  in  PLRS,  when  the  unit 
seeking  entry  must  transmit  a special  type  message  (called  a user  RAPID  report)  which  indicates  that  the  particular 
user  is  seeking  entry  into  the  network.  It  is  possible  that  such  special  messages  may  be  transmitted  simultaneously 
by  two  users  seeking  entry  into  the  network,  but  the  message  structure  is  such  that  such  simultaneous  occurrences 
will  not  disrupt  normal  network  signalling. 

F.  Diamond 

Are  there  any  plans  for  interoperation  of  the  two  systems? 

Authors’  Reply 

Yes,  the  Army  has  funded  Jiughes  Aircraft  Co.  to  further  define  and  evaluate  a system  which  integrates  PLRS  and 
JTIDS  to  satisfy  the  Army’s  data  distribution  and  position  location  reporting  requirements.  This  effort,  called 
ADDS  Mk  1,  is  directed  at  assessing  the  design  and  feasibility  of  combining  PLRS  and  JTIDS  to  that  end. 
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SUMMARY 


DME  and  video  guidance  for  tactical,  unmanned  vehicles  operating  in  an  EW  environment  place  a multiplicity 
of  requirements  on  the  communications  data  links  used  for  command  control.  Anti-jam,  multiple  access, 
variable  bit  rates,  ranging,  low  probability  of  intercept  and  multipath  discrimination  are  all  necessary 
to  achieve  positive,  real-time  control.  On  top  of  this  multi-functional  capability  resides  the  driving 
forces  of  low  cost  and  effective  spectrum  utilization.  By  integrating  temporal  and  spatial  signal  process' 
ing,  the  multi-function  communications  requirements  can  be  generally  met  with  moderate  bandwidths.  By 
proper  design,  fully  adaptive  transceivers  with  a single  spread  spectrum  signalling  structure  can  be 
derived  with  multi-mission  capabilities.  Such  transceivers  at  moderate  bandwidths  are  realizable  by 
incorporating  the  new  solid  state,  programmable,  signal  processing  device  technologies  and  microcomputer 
technology.  The  mul ti-missiog  capability  leads  to  large  transceiver  production  buys  and  standardizes 
the  form,  fit  and  function  (FJ)  parameters.  Moderate  bandwidths  with  solid  state  implementation  min- 
imizes these  F3  parameters.  A single  spread  spectrum  signalling  structure  leads  to  duplicity  of  circuits, 
increasing  the  use  of  mass  production  processes.  All  of  these  factors  combined  not  only  lead  to  low  cost 
transceivers  but  also  to  lower  overall  vehicle  costs. 

1 . INTRODUCTION 

Tactical  data  links  for  the  command  and  control  of  manned  or  unmanned  vehicles,  operating  in  an  ECM  en- 
vironment, present  significant  technological/economical  challenges.  The  unmanned  vehicle,  particularly, 
presents  a problem  in  which  technology  and  economics  are  inextricably  bound  together  into  a classical 
"approach-avoidance"  conflict.  While  the  state-of-the-art  in  ECCM  technology  appears  able  to  support 
immediate  fabrication  of  the  required  data  link  equipment,  the  economics  of  the  situation  definitely 
requires  caution  be  exercised  in  developing  the  data  link  specification.  By  economics  in  this  case  we 
can  mean  both  physical  factors  and  spectrum  utilization,  in  addition  to  cost.  However,  physical  factors 
are  so  interrelated  with  cost,  for  instance,  aircraft  modification  and  integration  costs  often  comprise 
505S  of  the  cost  of  an  air  borne  system,  that  we  will  restrict  ourselves  to  cost  and  spectrum  utilization, - 
the  later  being  of  great  concern  in  the  dense  NATO  environment. 

As  an  example,  with  the  availability  of  gigabit  modem  techniques,  it  would  appear  possible  to  build  an 
anti-jam  video  (imagery)  data  link  with  large  jam  resistance  for  weapon  guidance.  The  desireabil ity  of 
such  a link  is  without  question.  At  the  same  time,  however,  we  are  faced  with  the  desires  to  incur  as 
low  a cost  per  weapon  as  possible,  because  of  the  expendable  nature  of  the  system  as  well  as  budgetary 
constraints  and  to  utilize  as  small  a bandwidth  as  necessary,  because  of  the  realities  of  frequency 
allocations.  The  conflict  here  is  quite  obvious. 

Expendabil ity , however,  is  not  the  only  factor  which  impacts  economical  considerations.  Expandability  is 
related  to  offensive  or  strike  missions  and  is  relevant  whether  the  guidance  is  by  DME  or  imagery.  When 
one  adds  surveillance  and  reconnaissance  missions  to  the  list  of  tactical  data  link  applications,  the 
impact  of  vehicle  cost  takes  on  added  meanings.  First  of  all,  because  all  three  are  different  missions 
with  some  different  command  and  control  requirements,  the  tendency  has  been  to  design  special  data  links 
for  each  of  the  missions  and,  in  some  cases,  to  design  a special  data  link  for  each  type  of  air  frame 
assigned  to  the  same  mission.  This  has  led  to  the  now  much  criticized  "proliferation"  of  data  links,  and 
the  popular  thought  that  vehicle  costs  and  hence  the  impact  on  the  budget  could  be  reduced  if  the  number 
of  types  of  data  links  could  be  reduced  (i.e.  mass-production).  While  there  is  room  for  direct  cost 
reduction  arguments  in  this  line  of  thought  (e.g.  size  of  the  cost  reductions  for  a limited  buy  when 
compared  to  commercial  volumes  and  resulting  impact  on  performance),  It  has  resulted  in  a second  level  of 
proliferation  based  upon  mission  also.  By  reducing  the  number  of  types  of  data  links,  for  example,  to  a 
command  link,  a DME  guidance  link,  an  imagery  guidance  link  and  a small  number  of  prime  mission  equip- 
ment links,  particular  missions  could  be  satisfied  by  combining  the  standard  links.  This  approach, 
however,  results  in  a requirement  to  accommodate  a multiplicity  of  possible  on-board  data  link  equipment. 

As  an  example,  a particular  airframe  may,  in  one  case,  be  required  to  accommodate  a DME  guidance  data 
link  with  associated  RF  equipment.  Video  guidance  is  then  achieved  by  "adding  on"  a standardized  video 
downlink  package,  increasing  size,  weight  and  prime  power  requirements  above  that  of  the  standardized 
DME  package.  The  effectiveness  of  this  approach  in  reducing  vehicle  or  weapon  cost  is  questionable. 

While  the  approach  may  be  a matter  of  necessity  In  the  near-term,  it  certainly  is  not  for  the  long  term. 
There  have  been  efforts  for  designing  and  implementing  integrated  waveforms  (Kivett,  J.  A.,  Bowers,  G. 

F.,  1973). 

2.  MULTI-FUNCTION  REQUIREMENTS 

At  the  recent  AGARO  Avionics  Panel  meeting  in  Munich,  Diamond  et  al  reviewed  the  rapid  progress  in  new 
signal  processing  device  technologies  and  alluded  to  their  Integration  into  a fully  adaptive  transceiver 
which  may  provide  some  relief  from  this  apparent  conflict.  However,  before  we  get  into  this  possible 
solution,  we  should  examine  the  functions  required  of  the  data  links  for  command  and  control  of  unmanned 
vehicles.  These  functions  are  summarized  in  Figure  1. 

We  wish  to  exercise  real-time  or  near  real-time  positive  control  of  the  vehicle.  The  means  of  control 


will  be  provided  by  an  anti-jam,  multiple  access  communications  data  link.  In  a great  many  cases  this 
link  will  be  operating  over  a 1 Ine-of-slght,  ground-air-ground  channel  and  we  must  accommodate  propa- 
gation anomalies,  particularly  multipath.  Positioning  or  navigation  of  the  vehicle  can  be  accomplished 
by  either  DME  (which  then  requires  a ranging  function)  or  by  backl Inked  Imagery.  The  final  function, 
which  may  or  may  not  be  of  concern  for  a specific  mission  is  that  of  low  probability  of  Intercept. 

We  can  define  the  problem  then  as  the  most  economical  implementation  of  these  functions  as  possible. 

The  approach  we  propose  Is  the  opposite  of  the  separation  of  functions  - It  is  the  integration  of 
functions,  lhat  is,  we  consider  the  totality  of  the  C3  functions  as  being  a single  function,  and  we 
make  that  function  the  sole  and  only  responsibility  of  the  data  link.  This  approach  Is  based  upon  a 
few  simple  concepts: 

1.  Communications  Is  moving  toward  an  eventual  all  digital  format. 

2.  The  emphasis  on  commonality  and  standardization  of  data  link  equipment  Is  being  extended  to 
equipment  and  information/data  message  standards,  with  movement  toward  eventual  NATO  standards. 

3.  A single  spread  spectrum  signalling  structure  can  inherently  satisfy  all  the  C3  requirements. 

4.  Technology  will  support  reprogrammable  signal  processing. 

The  implications  of  these  concepts  are  that  the  data  link  becomes  disassociated  with  the  user  functions, 
that  is  becomes  "transparent".  We  partition  the  data  link  at  the  user  RF/Modem  IF  interface  and  at 
the  modem  baseband/user  baseband  interface  and  accept  the  realities  of  frequency  allocations  as  well  as 
the  need  to  accommodate  different  types  of  users.  However,  we  do  not  accept  the  fact  that  the  data  to/ 
from  the  modem  and  the  IF  signal  to/from  the  modem  have  to  be  different  signalling  structures  for  one 
form  of  guidance  as  compared  to  the  other. 

3.  DESIGN  STRATEGY 

The  separation  of  modem  and  data  source/sink  provides  a great  flexibility  in  the  application  or  use  of  the 
modem.  The  same  form  of  direct  sequence  spread  spectrum  modulation  would  be  used  on  both  the  forward  link 
and  back  link  and  the  same  keying  rate  used  also.  The  suggested  modulation  is  some  form  of  weighted  off- 
set, quadriphase  shift  keying  (QPSK)  at  an  I and  Q channel  rate  of  10  Mbps,  giving  a 20  Mbps  overall  rate. 
Weighted,  offset,  QPSK  is  an  economical  waveform  because  it  concentrates  in-band  energy  with  low  side- 
lobes  allowing  use  of  saturated  linear  amplifiers  and  close  stacking  when  more  than  one  channel  is  needed. 
I and  Q channel  operation  at  10  Mbps  is  in  the  realm  of  CMOS  LSI  implementation  and  20  Mbps  would  be  a 
realistic  allocation  to  obtain.  Furthermore,  using  the  same  modulation  on  both  links  at  a single  keying 
rate  means  that  the  circuits  in  the  controlled  vehicle  modem  and  control  station  modem  are  duplicative, 
reducing  specialization  and  leading  to  even  more  use  of  mass  production  processes. 

The  control  station  and  vehicle  modems  are  block  diagrammed  in  Figures  2 and  3.  Review  of  the  diagrams 
illustrates  the  transparency  of  the  modems  and  the  duplicity  of  circuits.  The  control  station  modem 
shows  that  ranging  is  an  inherent  property  of  spread  spectrum  systems,  and  can  be  accomplished  independ- 
ent of  both  the  type  of  data  and  the  demodulation  process.  As  shown,  two-way  ranging  performed  at  the 
control  station,  rather  than  one-way  ranging  at  the  vehicle,  puts  the  range  measurement  unit  (RMU) 
external  to  the  modem.  That  is,  the  RMU  is  user  equipment  for  those  systems  employing  DME  guidance. 

A more  important  implication  is  that  the  burden  of  RMU  cost,  size,  weight  and  prime  power  drain  is  removed 
from  the  vehicle/weapon  and  placed  in  the  control  station,  and  fewer  control  stations  will  be  required 
than  vehicles/weapons. 

In  the  DME  case  illustrated,  the  telemetry  downlink  from  the  vehicle  would  contain  whatever  data  is 
necessary  for  reporting  vehicle  control  status,  while  providing  for  the  round  trip  DME  ranging  measure- 
ment. For  those  systems  using  video  guidance,  the  telemetry  downlink  would  contain  the  digitized  video 
and  the  range  measurement  unit  is  simply  not  applied.  This  provides  the  control  station  with  the  cost 
effective  capability  of  handling  both  types  of  systems  such  as  day  and  night  oriented  weapons  with  the 
same  data  link  equipment.  However,  since  some  vehicle  status  reporting  is  usually  required,  even  for 
those  with  video  guidance,  multiplexing  of  the  digital  low  rate  status  and  the  higher  rate  video  data, 
as  shown  in  Figure  4,  results  in  a single  RF  transmission  from  the  vehicle.  In  a like  manner,  for  a 
DME  system,  other  on-board,  user  oriented  equipment  could  be  accommodated  by  multiplexing  with  the 
status  data  on  the  downlink.  The  sufficiency  of  a single  downlink  RF  transmission  maintains  low  vehicle 
overall  F3  and  cost  factors,  while  not  incurring  any  increase  in  probability  of  detection. 

The  20  Mbps  example  PN  clocking  rate  would  place  constraints  on  the  amount  of  downlinked  data.  Full  525 
line,  eight  grey-level  digitized  video  could  not  be  accommodated.  However,  as  initially  pointed  out, 
affordable  jam  resistant  video  for  expendable  missions  will  most  likely  be  based  on  data  compression 
which  provides  sufficient  resolution.  Since  good  progress  has  been  made  in  this  area  and  we  are  direct- 
ing ourselves  to  the  long  term,  the  availability  of  a sufficient  data  compression  technique  or  techniques 
is  assumed.  Thus  the  range  of  downlink  data  rates  would  extend  from  status  only  (with  maximum  process- 
ing gain)  up  to  a multiplexed  maximum  of  20  Mbps  (no  processing  gain).  The  example  in  Figure  4 shows 
how  processing  could  be  shared  and  traded  between  status  and  sensor  data.  It  should  be  noted  that  for 
those  cases  where  the  downlinked  data  rate  approaches  the  PN  clocking  rate,  adaptive  antenna  nulling 
may  be  the  only  protection  available  at  the  receiving  control  station. 

While  modem  transparency  seems  feasible,  at  least  within  specific  classes,  there  is  the  question  of 
implementing  the  downlink  data  rate  selectabil  ity.  The  selectabil  ity  is  not  a problem  for  expendable 
vehicles.  The  downlink  rate  would  be  set  at  the  time  of  manufacture  for  the  particular  guidance.  Select- 
ability  would  be  handled  differently  for  the  control  station  and  vehicles  intended  for  non-expendable 
missions.  As  previously  stated,  we  would  like  to  have  some  control  stations  capable  of  handling  either 
DME  or  video  guided  vehicles.  For  another  reason,  vehicles  intended  for  non-expendable  missions  could 
become  multi-mission  by  no  more  extensive  a mod  than  changing  sensor  heads.  Data  rate  selectabil ity 
for  these  modems  would  be  achieved  by  incorporating  microprocessor  control.  Figure  5 illustrates  how 


microprocessor  timing  control  could  be  used  to  implement  a selectable,  multiplexed  data  rate  capability 
through  control  of  the  clocking.  Of  course,  the  fixed  master  clocking  feature  of  the  design  facilitates 
this  capability.  Figure  6 shows  that  the  control  station  would  maintain  control  of  the  situation  through 
mode  control  commands  (sensor/status  data  clocking  rates)  to  the  microprocessor  via  the  uplink  itself. 

In  the  control  station  modem  a microprocessor,  similarly  placed,  would  provide  for  generation  of  the 
selectable  data  rate  message  to  the  uplink  modulator  (by  punched  in  commands  for  Instance),  in  this 
manner,  changing  the  downlink  mode  can  be  made  even  during  the  mission. 

So  far  emphasis  has  been  placed  on  the  downlink,  for  obvious  reasons,  and  little  has  been  said  about  the 
uplink.  From  the  point  of  view  of  vehicle  control  and  modem/sensor  control,  a message  oriented  rather 
than  a continuous  bit  stream  uplink  may  be  more  desirable.  This  provides  for  the  use  of  "canned"  messages, 
taking  full  advantage  of  the  microprocessor,  and  allowing  for  more  meaningful  error  control  by  working 
with  the  total  message  rather  than  individual  bit  errors.  Messages  (or  block)  error  detection  with 
requested  message  repeating  is  straight  forward  to  implement  and  provides  positive  control  (emphasizing 
correct  through-put  of  the  total  command).  The  size  of  the  message  and  the  rate  of  each  command  can  be 
easily  adapted  through  the  microprocessor  to  satisfy  the  requirements  of  the  various  controlled  vehicles. 
Again  these  instructions  can  be  punched  in  at  the  control  station  prior  to  or  during  the  mission,  adapt- 
ing the  link  to  changing  requirements.  While  not  degrading  the  importance  or  vulnerability  of  the  up- 
link, the  message  formatting  is  actually  the  only  outstanding  difference  from  a conventional  spread 
spectrum  data  link  approach.  Figure  7 gives  two  example  uplink  structures.  Microprocessor  control  of 
the  clocking  allows  variability  of  the  update  rate,  number  of  messages  per  update  and  number  of  bits 
per  message.  Therefore,  the  processing  gain  can  also  be  varied.  Furthermore,  the  functional  separation 
of  the  modem  and  data  source  (e.g.  transparency)  with  computer  control  allows  for  repeated  messages  if  a 
message  is  missed  at  the  vehicle  or  for  redundancy  if  a message  is  particularly  critical. 

4.  MULTIPATH 

The  above  discussion  has  been  limited  to  the  transfer  of  data  without  any  consideration  of  the  channel. 

As  noted,  one  of  the  "multiple"  functions  to  be  performed  by  the  data  link  equipment  is  resolution  of 
channel  anomalies.  Performance  and  cost  can  be  greatly  impacted  by  the  characteristics  of  the  propa- 
gation media,  and  poor  weather  is  not  uncommon  in  Europe.  Of  particular  concern  is  multipath  distortion, 
either  discrete  refractive  (atmospheric)  or  specular  (ground).  A comprehensive  treatment  of  multipath 
in  the  line  of  sight  channel  has  been  undertaken  (RADC-TR-75-233;  Bello,  P.  A.  et  al , 1973)  and  the 
general  problem  areas  in  relation  to  direct  sequencing  systems  are: 

(a)  Degraded  error  rates,  loss  of  signal  and  reacquisition  problems  due  to  fading. 

(b)  False  lock  onto  strong  atmospheric  multipath  and  subsequent  loss  of  synch  as  it  disappears 
during  flight  path  dynamics. 

(c)  Ranging  and  Doppler  uncertainties  as  they  effect  acquisition  time  and  strategy. 

(d)  Improper  nulling  by  adaptive  antenna. 

As  has  been  pointed  out,  however,  (Patti,  J.  J.,  Roeder,  A.  W.,  1975)  if  properly  treated,  the  effects 
of  multipath  on  correlation  receivers  can  be  minimized  and  in  some  cases  its  occurrence  can  be  used  to 
improve  link  reliability.  Such  cases  for  improvement  occur  when  the  parameters  of  the  channel  vary  at 
a much  slower  rate  than  the  data  rate  and  the  multipath  is  resolvable.  By  using  a record  of  the 
channel  developed  in  a smoothing  filter,  the  energy  in  the  multipath  components  can  be  combined  into 
the  detection  process,  instead  of  rejected  as  in  conventional  spread  spectrum  processing.  The  result 
is  an  increased  signal  to  noise  ratio  with  subsequent  improvement  in  error  rate.  The  observations  have 
been  equivalent  at  times  to  that  obtained  by  error  correction  against  multipath.  It  is  significant  that 
the  improvement  is  obtained  without  an  increase  in  spectrum  utilization. 

5.  ADAPTIVE  ANTENNA 

Previous  remarks  have  alluded  to  integrating  adaptive  antenna  nulling  techniques  with  the  spread  spectrum 
modem  to  achieve  the  total  jam  resistance  of  the  design  strategy.  Adaptive  antenna  nulling  is  a process- 
ing which  provides  spatial  discrimination  against  undesired  signals.  Conceptually  this  discrimination 
appears  as  in  Figure  8.  That  is,  via  some  algorithm,  the  normal  pattern  of  a receive  array  can  be 
adapted  to  place  nulls  in  the  direction  of  undesired  signals  while  maintaining  main  beam  coverage  of  the 
desired  signal.  The  adaptation  is  achieved  by  control  of  amplitude  and  phase  weights  at  each  element  in 
the  array  so  as  to  optimize  some  performance  measure.  A good  approximation  is  that  for  an  N element  array, 
nulls  can  be  placed  on  N-l  undesired  signals. 

This  form  of  processing  is  a subject  all  in  itself  and  reference  is  made  to  several  symposiums  (IEEE  AP-S, 
1976;  NRS  Meeting,  1978).  However,  some  general  remarks  will  be  made  as  they  effect  the  design  strategy. 

A generic  processor  is  block  diagrammed  in  Figure  9.  The  processing  may  or  may  not  include  interaction 
with  the  modem. 

The  simpler  form  of  processing  is  without  modem/array  interaction.  That  is  the  processing  is  autonomous. 

An  example  of  this  case  is  the  large  signal  suppression  algorithm  or  power  inversion  algorithm.  The 
adaptive  processor  attacks  those  input  signal (s)  above  a certain  threshold  and  attempts  to  drive  these 
signals  back  down  to  the  threshold  in  a reciproca1  suppression  manner.  The  spread  spectrum  processing 
gain  then  allows  delineation  of  the  desired  signal.  As  straightforward  and  effective  as  such  processing 
can  be,  it  does  not  protect  against  main  beam  interference  ind  requires  adapting  the  threshold  over  the 
dynamic  range  of  the  desired  signal. 

The  particular  mission  geometry  will  determine  if  main  beam  interference  would  be  a problem.  If  it  is, 
then  a desired  signal  reference  function  is  needed  to  discriminate  amongst  those  signals  appearing  in 
the  main  geam.  In  these  cases  there  must  be  an  interaction  between  the  modem  and  array  processor.  Such 
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interaction  may  be  uniquely  defined  for  each  signalling  structure  and  cannot  be  briefly  discussed.  As 
with  the  modem  control  functions  previously  described,  the  microprocessor  provides  the  flexibility  re- 
quired for  controlling  the  functions  of  the  adaptive  array  in  the  dynamic  scenarios  considered.  Adapt- 
ing the  threshold/decision  point  of  desired/undesired  signal,  varying  the  integration  or  convergence 
time  in  the  feedback  loops  in  response  tc  changes  in  the  environment  and  implementing  constraints  on 
beam/null  formation  are  several  of  the  adaptive  functions  which  could  be  placed  under  microprocessor 
control . 

6.  GENERIC  TRANSCEIVER 

The  generic  transceiver  block  diagram  appears  in  Figure  10.  It  is  obvious  that  the  strategy  of  flexible, 
multi-function  communications/  modem  transparency  is  based  on  the  emergence  of  two  technologies.  One 
is  microcomputers  to  execute  the  distributed  processing  for  control  of  the  multiple  functions,  the  other 
is  programmable  signal  processing. 

Referring  to  the  figure,  the  microcomputers  reside  in  the  timing  and  control  block,  with  the  double  ended 
arrows  indicating  the  distributed  processing.  Computational  complexity  and  execution  speed  required  would 
be  matched  at  each  of  these  levels  of  control.  (Single  chip  microcomputer  technology  of  the  early  and 
mid  80's  should  quite  comfortably  satisfy  these  requirements.  It  is  projected  that  in  the  early  80's, 

16  bit  single-chip  microcomputers  will  be  available  with  32K  ROM's  and  RAM's,  and  speeds  may  approach 
100  MHz  in  bipolar  implementations.  Random  access  memories  themselves  will  be  in  the  hundreds  of 
thousands  of  bits  sizes,  with  costs  of  0.01  cents/bit.  Isoplanar,  silicon-gate  implementations  may 
provide  20  MHz  operations  at  extremely  low  power  drain.)  Master  control  would  be  executed  through  a 
hierarchical  architecture,  implemented  most  likely  in  high  speed  bipolar  technology.  Memory  speed  and 
capacity,  available  during  this  period,  will  be  sufficient  to  accomplish  interprocessor  communications. 

In  addition  to  performance  flexibility,  distributed  processing,  effected  in  this  manner,  will  yield 
graceful  degradation  rather  than  catastrophic  failure. 

The  control  levels  in  the  adaptive  antenna  processor  are  illustrated  for  one  channel.  The  technology 
employed  to  implement  the  channel  is  relatively  straightforward.  Control  of  the  feedback  loop  integration 
time,  in  response  to  a changing  signal  environment,  can  be  achieved  either  in  hardware  (by  selecting 
amongst  a group  of  filters)  or  in  software.  Desired  signal/undesired  signal  decision  threshold  adaptation 
is  achieved  by  control  of  the  amplifier  noise  floor.  Beam/null  formation  constraints  are  achieved 
through  voltage  controlled  attenuators  in  the  complex  weight  circuit.  An  example  organization  of  this 
channel  and  its  amenability  to  such  control  is  illustrated  in  Figure  11,  which  shows  a hybrid  microwave 
integrated  circuit  implementation.  Significantly,  much  of  the  information  required  to  derive  the  control 
signals  is  developed  in  the  modem,  particularly  the  colored  noise  filter,  and  communicated  amongst  the 
specific  microcomputers  through  the  distributed  processing  procedures. 

In  the  temporal  processing  area  of  Figure  10,  the  possible  control  levels  are  multitudinous,  and  we  will 
only  illustrate  the  technology  base  as  it  relates  to  some  of  the  signal  processing  functions.  Pseudo- 
noise, direct  sequence  code  generation/detection  for  synchronization  preamble  and  data  jam  resistance, 
data  demodulation,  smoothing,  bandpass  filtering,  A/D  conversion  and  frequency  synthesis  are  all  functions 
amenable  to  either  surface  acoustic  wave  (SAW),  charged  coupled  device  (CCD)  or  customized  LSI  implementa- 
tion technologies.  The  emergence  and  progress  of  these  technologies  into  communications  signal  process- 
ing has  been  reviewed  recently  (IEE,  1976;  AGARD,  1977).  While  baseband  and  intermediate  frequency 
circuits  represented  the  majority  of  the  subject  areas,  recent  advances  in  magnetostatic  surface  waves 
(Collins,  Owens,  1978)  show  promise  for  providing  RF  signal  processing  circuits  also.  Filters  and  delay 
lines,  which  will  impact  both  the  physical  and  performance  characteristics  of  the  transceiver,  are  within 
technological  feasibility.  Of  particular  importance,  however,  are  multiple  tapped  delay  lines  with  tap 
programmable  amplitude  and  phase  coding  properties.  It  is  the  complete  programmability  of  these  lines, 
when  coupled  with  the  microcomputer,  that  leads  to  real  time,  adaptability  of  the  modem  and  hence  the 
transparent,  mul ti-mission  nature  of  the  data  link.  Shown  in  Figure  12  are  monolithic  CCD  and  monolithic 
SAW  programmable  tapped  delay  lines.  The  CCD  device  is  32  chips  long  at  2 Mbps  (RADC-TR-75-233)  and  the 
SAW  device  is  31  chips  long  at  10  Mbps  (Hickernell,  1977).  Both  devices  are  monolithic  M0S  structures, 
have  demonstrated  serial  or  parallel  combinations  for  increased  processing  gain  and  are  being  integrated 
with  microprocessor  control  elements. 

7.  MULTIPLE  ACCESS 

While  the  multiple  access  aspects  of  the  design  strategy  have  not  been  addressed  specifically,  it  is 
obvious  from  Figure  7 that  the  uplink  message  structure  represents  either  time  division  multiple  access 
(TDMA)  or  continuous  broadcast  multiple  address  signalling.  In  either  case  a portion  of  the  "m"  bits/msg 
would  be  used  as  an  address  which  could  also  perform  as  synchronization  preamble  for  TDMA.  The  impact 
in  the  controlled  vehicle  modem  is  minimal  since  the  programmable  matched  filter  can  be  time  shared 
between  the  address/synch  preamble  detection  and  data  despreading  functions.  The  two  cases  illustrated 
in  Figure  7 shows  that  variable  multiple  access  control  situations  (i.e.  number  of  vehicles  under  control) 
can  be  accommodated  through  microprocessor  control  of  the  number  of  messages/frame  (N).  In  fact  this 
adaptability  can  be  accomplished  in  real  time,  if  desired.  A key  feature  of  data  link  transparency  as 
it  relates  to  multiple  access  is  that  the  addressing  function  may  also  be  made  a user  function.  That 
is  the  addresses  may  be  generated  external  to  the  modem,  as  with  the  command  data,  under  control  of  the 
command  and  control  computer.  This  provides  the  control  station  the  flexibility  to  prioritize  messages 
within  the  update  period  (frame),  adapting  the  uplink  to  each  vehicle's,  real-time  command  and  control 
requirements  rather  than  using  a fixed  format.  The  backlink  for  the  DME  only  case  is  directly  compatible 
with  TDMA.  This  will  maintain  a single  RF  chain  in  the  vehicle.  There  will  be  a reduction  in  the 
processing  gain  on  the  backlink  from  the  single  vehicle  case.  However,  in  tactical  applications,  the 
number  of  vehicles  under  simultaneous  DME  control  will  most  likely  not  be  large  enough  to  cause  a sig- 
nificant reduction.  For  video-only  backlinks  in  tactical  applications,  the  number  of  simultaneous  video 
transmissions  to  a single  control  receiver  should  be  such  that  code  division  multiple  access  (CDMA)  will 
perform  satisfactorily.  CDMA  is  compatible  with  the  design  strategy  and  again  a single  RF  chain  in  the 
vehicle  will  be  sufficient.  For  missions  requiring  a mix  of  simultaneous  DME  and  video  vehicles,  a 
second  RF  chain  would  obviously  be  required. 


L : 
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8.  CONCLUSION 


A flexible  (multi-function)  design  strategy  exists  which  leads  to  a "transparent"  data  link  concept, 
capable  of  accommodating  both  DME  and  compressed  video  command  and  control  requirements  for  unmanned 
vehicles.  The  strategy  Is  based  upon  a single  spread  spectrum  signalling  structure,  and, when  applied 
to  moderate  signalling  rates,  can  be  Implemented  through  advanced,  monolithic  technologies.  The 
transparency  concept  further  leads  to  a multi-mission  capability  within  groupings  of  data  rate  require- 
ments, increasing  the  possible  equipment  uses.  The  total  effect  in  this  case  is  to  drive  costs  down  by 
increasing  the  size  of  production  buys  and  maximizing  the  use  of  LSI  mass  production  processes. 
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Figure  1 Data  link  functions  required  for  C . 
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Figure  2 Transparent  controlled  vehicle  modem  block  diagram. 
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Figure  3 Transparent  control  station  modem  block  diagram. 
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Figure  4 Example  of  multiplexing  video  and  status  downlink  data. 
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SELECTABLE  DATA  RATE 


Figure  5 Example  of  microprocessor  control  of  clocking  to  achieve 
selectable  data  rate. 
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Figure  6 Mode  control  data  from  uplink  provides  commands  to  microprocessor. 
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Figure  7 Example  uplink  structures  showing  flexibility  achievable 
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Figure  8 Adaptive  antenna  nulling  pattern  and  processor  adapted  output 
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Figure  9 Generic  processor  block  diagram. 


TRANSCEIVER  SIMPLIFIED  BLOCK  DIAGRAM 


Figure  10  Block  diagram  of  generic  transceiver. 


Figure  11  Hybrid  microwave  integrated  circuit  implementation  of  un 
adaptive  processor  channel  . 
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Figure  12  Example  of  monolithic  CCD  and  monolithic  SAW  programmable 
tapped  delay  line  technology 
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SUMMARY 


The  combination  of  spread  spectrum  signaling  and  adaptive  array  antennas  is  recognized  to  provide 
significant  interference  or  jamming  resistance.  This  paper  investigates  the  effect  of  the  antenna 
array  on  a wideband  signal;  of  special  interest  is  signal  distortion  produced  by  the  nulls  of  the 
array.  An  analytical  model  is  developed  to  relate  array  characteristics  and  the  matched  filter  output 
for  a wideband  coherent  receiver.  The  distorted  output  is  written  as  the  sum  of  the  desired 
autocorrelation  function  and  its  derivatives.  If  the  signal  is  being  nulled,  the  derivatives  can 
easily  predominate  and  distortion  become  severe.  Results  are  specialized  to  the  case  of  a 
pseudo-noise  (PN)  - coded  carrier  "filtered"  by  a four-element  linear  array.  A comparison  with 
experimental  data  is  made,  and  several  conclusions  regarding  receiver  design  and  signal  choice  are 
drawn. 


1.  INTRODUCTION 

Adaptive  antenna  arrays  have  become  the  subject  of  considerable  investigation  in  recent  years.  In 
a typical  ,Haptive  array,  phase  and  amplitude  of  the  signal  at  each  receiving  element  are  weighted 
before  those  signals  are  summed.  The  value  of  the  element  "weights"  is  determined  by  an  algorithm 
which  seeks  to  minimize  the  effects  of  an  undesired  signal  (unintentional  interference  or  jamming) 
in  the  array  output.  In  their  simplest  and  best  understood  form,  these  algorithms  seek  to  minimize 
the  total  signal  power  output  of  the  array.  If  the  interference  is  much  stronger  than  the  desired 
signal,  then  the  array  will  form  spatial  nulls  in  the  direction  of  the  interference;  these  nulls  will 
have  sufficient  depth  to  roughly  equalize  the  signal  and  interference  power.  If  the  modulation 
technique  permits  communication  at  unity  signal-to-interference  power  ratio,  then  an  adequate 
measure  of  interference  rejection  may  be  achieved.  Of  course,  this  type  of  adaptive  array  will  also 
null  the  desired  signal  in  cases  where  the  interference  is  relatively  weak  or  is  absent;  this  effect 
often  limits  the  usefulness  of  the  technique. 

A significant  performance  improvement  may  be  achieved  in  cases  where  the  desired  signals  can  be 
electronically  and  reliably  distinguished  from  the  interference.  The  array  algorithm  can  then  avoid 
nulling  the  desired  signals  and  can  concentrate  the  resources  of  the  array  entirely  on  interference 
rejection.  An  especially  strong  synergism  exists  between  spread-spectrum  modulation  schemes  and 
adaptive  arrays.  Not  only  does  the  structure  of  the  signal  provide  a reliable  discriminant  for  the 
adaptive  array,  but  the  "processing  gain"  of  the  modulation  technique  provides  interference  rejection 
over  and  above  that  furnished  by  the  array.  Current  technology  easily  permits  the  use  of  pseudo-noise 
(PN)  phase-coded  spread  spectrum  signals  in  combination  with  adaptive  arrays,  and  recent  experimental 
work  [COMPTON,  1978)  indicates  that  the  scheme  holds  promise.  Because  of  the  complicated  frequency 
dependence  of  array  antennas,  the  practical  combination  of  frequency-hop  spread  spectrum  and  adaptive 
arrays  appears  to  be  several  years  away. 

The  use  of  wideband  signals  with  adaptive  arrays  raises  several  questions  which  must  be  carefully 
studied  prior  to  implementing  such  a system.  Of  fundamental  concern  is  the  effect  that  the 
antenna  has  on  the  desired  signal.  Sophisticated  receivers,  especially  those  using  matched  filter 
or  correlator  detectors,  can  be  quite  sensitive  to  the  phase  and  amplitude  distortions  which  an 
adaptive  array  might  produce.  These  distortions  can  be  roughly  divided  into  two  classes:  static  and 
dynamic.  Static  effects  are  those  which  are  inherent  in  the  frequency-sensitive  nature  of  an  antenna 
array  and  which  persist  when  the  array  weights  are  fixed.  Dynamic  effects  are  due  to  the  adaptive 
nature  of  the  array  and  the  time  varying  (or  noisy)  spatial  response  it  produces. 

Dynamic  effects  are  usually  conjectured  to  be  the  more  serious;  the  classical  example  is  "weight 

noise"  modulation  of  the  phase  and  amplitude  of  a signal  being  nulled  [BERN  1 , 1978;  BRENNAN,  et.  al . , 1977]. 

They  are  also  the  more  elusive  analytically,  and  are  highly  dependent  on  the  particular  implementation. 

It  is  the  object  of  this  paper  to  study  the  distortion  produced  by  a static  array  antenna.  In 
particular,  we  shall  examine  distortion  of  the  output  of  a matched  filter  or  signal  correlator 
(i.e.  of  the  signal's  time  autocorrelation  function)  when  the  signal  is  "filtered"  by  passage  through 
an  array  antenna.  We  will  ignore  the  practical  aspects  of  dispersive  or  nonlinear  elements,  nonideal 
filters,  etc.,  and  will  concentrate  on  the  fundamental  effects  of  an  ideal  linear  array. 

(A  more  complete  analysis  for  both  static  and  dynamic  arrays  is  presented  elsewhere  [RASKA,  19781.) 

2.  ARRAY  FILTERING  EFFECTS 

We  consider  the  antenna  array  geometry  shown  in  Figure  1.  The  arriving  signal  is  assumed  to  be  of  the 
form 

a(t)  « A(t)cos(2itfQt  + 4>(t))  (1) 

where  Aft)  and  *(t)  are  the  amplitude  and  phase  .respectively,  of  the  rf  carrier  at  frequency  fQ. 
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Fcr  simp) icity,  we  introduce  the  complex  envelope  representation 


a ( t ) = Re(s(t)exp [+j2nfQt) ) 


s ( t ) = A(t)exp[+j<)>-,t)l  (3) 

and  Re(-)  denotes  the  real  part  of  the  enclosed  quantity.  Since  we  are  not  considering  dispersive 
effects  of  the  array  elements,  the  primary  effect  of  the  array  is  to  introduce  time  delays  and  amplitude/ 
phase  changes  between  the  signals  at  the  various  antenna  elements.  Using  the  definitions  for  the 
complex  envelope,  it  is  straight  forward  to  demonstrate  that  when  the  signal  is  delayed  by  an  amount 
t.  i.e.  a(t-t.),  it  has  a complex  representation  s ( t-t . )expt-j2irfot. ] . If  we  further  assume  both 

amplitude  and  phase  modulation  can  be  introduced  at  each  element  the  resulting  N-element  array  output 
becomes  (in  complex  form) 


II 

y(t)  = l w. (t)s(t-t . )exp[-j2uf  t .1 
i=l  1 1 01 


where  the  {w. (t)}  are  the  complex  element  weights  and  the  (t.)  are  the  differential  time  delays  of  the 

signal  propagating  across  the  array.  Note  from  the  geometry  in  Figure  1 that  the  time  delays  are 
very  much  dependent  on  the  arrival  angle  of  the  signal,  that  is,  we  could  be  more  explicit  and  write 
{^(8)}. 

2.1  Matched  Filter  Output 

Suppose  the  array  output  y(t)  is  passed  through  a filter  matched  to  s(t).  If  the  weights  are  static 
(independent  of  time),  the  resulting  output  is  given  by 

N _ 

r(t)  = y w.exp[-j2irf  t.ir  (T-t.)  (5) 

i=l  1 o l s l 

where  r ( t)  is  the  time-autocorrelation  function  of  the  signal  s(t).  Typically,  autocorrelation  pulses 

may  be  on  the  order  of  microseconds  wide  while  propagation  delays  are  on  the  order  of  nanoseconds; 
thus  a cormion  approximation  is  to  write  (5)  as 


r(r)  ~ { J w.exp  i-j2irf  t . ]}  r (t) 
i=l  1 o l s 


The  reader  will  recognize  the  term  in  brackets  as  the  "array  factor"  of  the  antenna  at  frequency  f0 
[STEINBERG,  1976).  Equation  (6)  is  commonly  used  to  describe  the  array  output  whenever  the  incoming 
waveform  is  "narrowband".  We  will  demonstrate  that  (6)  is  in  general  a poor  approximation,  especially 
if  the  signal  is  arriving  in  the  vicinity  of  an  antenna  null. 

2.2  The  Array  Filter  Response 

To  show  the  desired  filtering  result,  we  start  by  obtaining  the  Fourier  transform  of  (5), 


Y(f)  = y w.exp  l-j2ir(f  + f)t.]  S(f ) 
i=l  1 01 


where  Y(f)  and  S(f)  are  the  Fourier  transforms  of  y(t)  and  s(t),  respectively.  The  matched  filter 
output  (in  the  frequency  domain)  then  becomes 

. N 

R(f)  = |S(f)n  I Wlexpt-j2w(f  + f )t, (0)1) 
i=l  1 01 

= |S(f)|2H(f,9) 


In  writing  (8),  we  have  again  emphasized  the  delays  are  arrival-angle  dependent.  Equation  (9)  merely 
states  that  the  static  array  can  be  viewed  as  an  angle-dependent  transfer  function  which  relates 
the  signal's  power  spectrum  to  the  matched  filter's  output  spectrum.  The  filter  H(f,8)  is 
dependent  only  on  array  geometry  (through  the  (t..))  and  the  elements  weights  {w^};  thus  it  has  no 

relation  to  the  incoming  signal  s(t). 

In  order  to  interpret  the  results,  we  first  expand  H(f,9)  in  a Taylors  series  about  f = 0 (recall 
we  are  using  a complex  baseband  model  to  represent  the  signals), 

H(f,9)  * a (9 ) + (j2irf )b(0)  + ( j2irf )2c(0)  ♦ •••  ( 


A 


The  matched  filter  output  can  now  easily  be  interpreted  using  the  derivative  rule  of  Fourier  transforms: 


r(t)  = a(9)rs(T)  + b(6)  rs(t)  + c(6)r’s(t)  + ••• 


(ID 


where  the  overdots  denote  derivatives  with  respect  to  the  variable  t.  Equation  (11)  indicates  that 
any  signal  distortion  is  dependent  both  on  the  array  characteristics  (throuqh  the  complex  coefficients 
a(0),  b(e),  •••)  and  on  the  signal  waveform  used  (through  rs(r),  rs(t),  •••).  Also,  since  the  coefficients 

are  complex  numbers,  the  various  terms  in  the  sum  are  not  generally  in  phase  thus  the  array  filter  may 
operate  differently  on  each  of  the  signal  quadrature  components,  resulting  in  both  an  apparent 
amplitude  and  phase  modulation  of  the  output  correlation  pulse. 

We  emphasize  that  our  results  in  (11)  is  a quite  general  complex  representation;  it  can  be  used  to 
interpret  communication  performance  of  envelope  as  well  as  coherent  detectors  used  at  the  matched  filter 
output. 

It  is  instructive  to  compare  (11)  to  the  commonly  used  approximation  (6).  The  first  term  in  (11)  is 
is  exactly  the  same  as  the  array  factor  in  (6)i  Thus  common  approximations  normally  involve  only  the 
first  term  in  the  Taylors  series  expansion  (11)-  This  can  be  an  expecially  poor  approximation  in  the 
vicinity  of  a null  where  a(0)  is  negligible  but  the  other  coefficients  may  not  be.  Such  a case  is 
illustrated  in  the  examples  to  follow. 

3.  EQUALLY  SPACED  LINEAR  ARRAY:  SIMULATION  RESULTS 

As  an  indication  of  the  type  of  results  expected,  suppose  the  array  consists  of  N elements  equally 
spaced  d meters  apart.  This  implies  the  time  delays  can  be  related  to  arrival  angle  through 


tj  = (i-1)  d cos  6,  1=1,2,*--  N. 


where  c is  the  speed  of  light.  Furthermore,  suppose  the  beam  is  steered  broadside  so  that  all  the 
(w.)  are  unity. 


The  transfer  function  H( f ,6 ) can  now  be  expressed  in  closed  form  [STEINBERG,  1976], 

j / Si n ( — (f  + f )d  cose) 

H(f.e)  = expi+j(N-l)^S  (f  + f)cos(e)]  £ 5 

C ° ^S1n(-jj-  (f  + fo)d  cos9)  / 

On  expanding  H(f,9),  we  obtain 

H(f,6)  = exp[+j(N-l)|^  (f  + f Jcosej. 


Sin(—  fQ  dcose) 


(13) 


v_  Sln(—  f0  cose) 

f I Fndf  cose\  CNnf-d  cose\  . Nnf„d  cose-.  / nf  d coses  , 

. I » Sin(-JL ) cos  ( ^ ) -S<i.(-&: ) c ( -^ ) \ 

( ndf„  \ 5>  ' 

Sin  \ ~c~  cos(e)Jd 

....  J 

Equation  (14)  merely  illustrates  how  the  coefficients  in  (11)  can  be  obtained.  We  are  unable  to  make 
further  generalizations  without  assuming  some  typical  parameters. 

3.1  Array  Filter  Characteristics;  Numerical  Example 


(14) 


Consider  a four  element  array  with  half-wavelength  spacing  at  a center  frequency  fQ  of  350  MHz.  Such 

a configuration  would  result  in  the  antenna  polar  pattern  shown  in  Figure  2.  Note  the  antenna  nulls 
occur  at  0°,  ”50°,  120°and  180°  in  the  upper  hem,  . ’here,  as  can  be  easily  predicted  from  (13).  The 
amplitude  and  phase  of  H(f,8)  are  presented  as  functions  of  frequency  for  various  arrival  angles 
in  Figure  3.  From  these  plots  we  observe: 

(1)  The  phase  is  a linear  function  of  frequency  with  its  slope  and  intercept  a function  of 

arrival  angle.  (The  discontinuity  results  at  the  origin  to  account  for  the  sign  change  in 
H(f,e)  at  the  origin).  Thus  any  nonlinear  phase  characteristics  observed  experimentally 
must  be  due  to  dispersive  effects  of  the  array  components  themselves. 

(ii)  The  magnitude  can  be  represented  as  a constant  plus  linear  term  in  frequency  over  a 

bandwidth  of  roughly  15%  of  the  center  frequency.  (The  constants  depend  strongly  on  the 
arrival  angle). 
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( i i 1 ) The  first  term  of  the  Taylor  series  is  adequate  to  represent  the  array  at  broadside 
while  the  linear  term  is  strongly  dominant  in  the  vicinity  of  a null. 


3.2  Output  Signal  Waveforms 

In  order  to  demonstrate  the  effects  on  signaling  waveforms,  we  first  assume  s(t)  has  a time  autocorrelation 
function  as  shown  in  Figure  4.  (This  corresponds  approximately  to  a PN  phase-coded  waveform  with 
a chip  width  of  2 microseconds  [DIXON,  1976].)  In  the  following  example,  we  show  four  possible 
waveforms  for  each  arrival  angle.  The  first,  denoted  as  the  "signal  quadrature"  component, 
corresponds  to  the  matched  filter  output  for  a phase  coherent  receiver  which  is  tracking  the  phase 
of  the  undistorted  signal  component.  The  second,  denoted  as  the  “derivative  quadrature",  corresponds  to 
the  output  of  a coherent  receiver  which  is  tracking  the  phase  of  the  derivative  component.  For 
the  numerical  example  presented,  these  signals  are  90°  out  of  phase;  thus  the  label  "quadrature" 
has  been  used  to  describe  the  two  signals.  The  "envelope"  plot  is  simply  the  output  waveform  observed 
with  an  envelope  detector.  Finally,  we  suppose  a phase  coherent  detector  is  used  where  the  reference 
phase  is  that  of  a signal  arriving  from  broadside  to  the  array;  the  resulting  waveform  is  denoted 
as  the  "real  axis"  output. 

Consider  first  the  case  when  the  signal  is  arriving  at  the  antenna  null  of  0°.  From  equation 

(14),  we  observe  that  the  un distorted  signal  component  is  identically  zero,  while  the  derivative 

term  is  nonzero.  These  results  are  confirmed  by  the  plots  shown  in  Figure  5,  which  shows  that  the 

dominate  output  waveform  is  due  to  the  derivative  of  the  signal  autocorrelation.  (The  "grass" 

on  the  waveforms  is  due  to  the  few  number  of  samples  used  in  the  Fast  Fourier  Transform  (FFT)  computations). 

It  is  also  interesting  to  note  that  the  output  (for  all  the  cases  examined)  is  nearly  zero  at  the 

pulse  center.  Thus  any  communication  system  designed  to  sample  the  correlator  output  at  the  pulse 

center  would  perform  extremely  poorly.  Of  course,  such  a conclusion  is  almost  automatic  in  the  usual 

system  analysis,  since  the  signal  is  arriving  in  an  antenna  null.  However,  we  do  observe  that 

an  additional  signal  component  (distortion)  is  present  in  the  output  and  that  component  is  very 

much  dependent  on  the  type  of  signal  used  (narrowband,  broadband,  etc.). 

Tg  illustrate  the  effects  of  arrival  angle,  we  present  the  output  waveforms  for  arrival  angle  of 
5 in  Figure  6.  Here  we  see  that  both  undistorted  signal  and  derivative  terms  are  present  in  the 
output.  On  comparing  Figures  6a  and  6b  we  conclude  the  signal  quadrature  is  roughly  a factor  of 
16  larger  than  the  derivative  quadrature.  Thus  it  is  obvious  that  the  envelope,  shown  in  Figure 
6(c),  should  be  dominated  by  the  undistorted  signal  term.  The  "real  axis"  signal,  shown  in  Figure  6(d), 
does  still  show  the  effect  of  both  components  in  the  output.  Thus  phase  coherent  detectors  can 
exhibit  a strong  sensitivity  to  array  distortion  effects  which  may  not  be  observed  with  an  envelope 
detector.  These  distortion  effects,  depending  on  receiver  design,  can  have  a profound  impact 
on  overall  communication  performance.  The  next  section  presents  experimental  results  which 
confirm  such  a conclusion. 


4.  EXPERIMENTAL  RESULTS 

The  results  presented  in  this  section  were  obtained  independently  and  predate  the  analysis  by  several 
years.  The  wideband  signal  was  a 127  chip  maximal  length  sequence  clocked  at  10  Mc/s  and  modulating  a 
40  MHz  IF  carrier.  This  signal  was  radiated  and  received  broadside  by  a two-element  adaptive  array; 
the  array  was  allowed  to  form  nulls  of  various  depths  in  the  direction  of  the  signal,  whereupon  its 
weights  were  frozen  and  data  taken.  The  array  output  was  processed  by  a spread-spectrum  demodulator 
employing  a 127  chip  SAW  device  matched  filter.  The  data  detector  was  phase-coherent  and  employed 
a conventional  phase-locked  loop  (PLL)  (loop  bandwidth  of  1 KHz)  to  track  the  carrier  phase  in  the 
matched- fi 1 ter  output  pulses.  The  synchrony  zation  scheme  employed  an  envelope  detector  which, 
because  of  the  particular  implementation  chosen,  required  significantly  greater  signal  to  noise  ratios 
than  did  the  data  detector.  Typically,  the  data  detector  BER  was  less  than  10‘5  at  the  signal  levels 
required  to  achieve  synchronization. 

The  experimental  setup  was  similar  to  Figure  1 except  that  the  array  had  only  2 elements,  the  signal 
arrived  broadside,  and  the  "matched  filter"  was  a somewhat  more  sophisticated  modem.  Interference 
consisted  of  thermal  noise  of  the  receiver. 

In  the  first  experiment,  the  modem  input  power  level  required  to  achieve  synchronization  was  found  as 
a function  of  null  depth.  This  is  shown  in  Table  I,  with  0 db  corresponding  to  the  level  required 
of  an  undistorted  (i.e.,  an  un-nulled)  signal. 


TABLE  I 

MODEM  PERFORMANCE  vs  NULL  DEPTH 

Null  Depth  (dB ) Relative  Signal  Level 
Required  for  Sync  (dB) 


0 

3.1 
8.5 
11  .8 
14.3 


0 

1 

4 

6 ( no  da  ta ) 

10.5  (no  data) 
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For  the  shallow  nulls.  It  was  possible  to  compensate  for  array-induced  distortion  by  increasing  modem 
input  power.  This  was  not  the  case  for  nulls  deeper  than  10  dB.  In  these  situations,  the  synchron- 
ization circuit  could  be  made  to  function  by  applying  sufficient  power  but  no  amount  of  input  power 
could  make  the  phase-coherent  data  detector  yield  a meaningful  output.  This  was  undoubtedly  due  to 
the  Pit's  inability  to  track  the  highly  distorted  phase  of  the  RF  structure  within  each  correlation 
pulse.  A photograph  of  the  undistorted  correlation  pulse  is  shown  in  Figure  7a  and  is  followed  by 
photographs  of  the  distorted  pulses  resulting  from  11.8  and  14.3  dB  antenna  nulls.  Although  the 
phase  distortion  cannot  be  seen,  t*e  characteristic  "derivative"  type  of  pulse  envelope  distortion 
derived  in  (11)  and  illustrated  in  Figt  e 5c  is  clearly  evident. 

The  transfer  function  of  the  adaptive  array  was  experimentally  obtained  by  using  sinusoidal  signals 
at  1 MHz  increments  and  measuring  the  array  output  with  a vector  voltmeter.  Figure  8 shows  the  results 
for  array  weights  yielding  11.8  dB  and  14.3  dB  wideband  nulls.  Except  for  the  phase  anomaly  occurring 
at  14.3  dB,  they  agree  qualitatively  with  the  analytically  derived  transfer  functions  of  Figure  3. 

"Phase  reversals"  such  as  shown  in  Figure  8(d)  are  often  observed  experimentally.  As  was  poirted  out 
in  the  preceding  section,  they  are  not  an  inherent  feature  of  array  antennas  but  are  probably  due  to 
phase-dispersive  components  of  the  hardware. 

5.  CONCLUSIONS 

Both  the  analysis  and  the  experimental  data  indicate  that  the  distortion  experienced  by  a wideband  signal 
when  it  is  nulled  by  an  array  antenna  can  be  severe,  even  for  moderate  null  depths.  In  the  particular 
case  where  the  signal  is  subsequently  matched-fil tered , the  distorted  filter  output  can  be  written  as  a 
weighted  sum  of  the  undistorted  output  and  its  derivatives.  Coefficients  in  the  sum  depend  on  arrival 
angle  and  array  weights;  the  derivative  terms  can  be  significant  in  a wide  angle  about  the  null,  and 
dominate  near  the  center  of  the  null.  For  signals  whose  relative  bandwidth  is  less  than  10%,  only  the 
first  derivative  is  significant. 

The  array  phase-transfer  function  is  linear,  and  the  magnitude  transfer  function  can  be  highly  irregular 
and  non-symmetric  about  the  center  frequency.  Signal  distortion  is  due  entirely  to  the  magnitude 
transfer  function;  the  non-symmetry  of  this  function  can  greatly  distort  the  "phase"  of  a wideband 
signal  and  its  matched-filter  output. 

When  designing  wideband  systems  which  use  phased-array  antennas,  especially  adaptive  arrays,  it  is 
extremely  important  to  choose  signal  and  detector  structures  which  are  robust  to  these  effects.  If  there 
is  a possibility  that  a desired  signal  can  be  nulled,  then  extreme  caution  should  be  exercised  in  employ- 
ing phase-coherent  detectors  or  even  incoherent  (envelope)  detectors  which  rely  on  the  shape  of  the 
matched-filter  output  envelope.  It  is  considerably  safer  to  use  differential  encoding  schemes  where  the 
data  resides  in  pul se-to-pul se  characteristics,  and/or  detector  structures  which  are  insensitive  to  the 
shape  of  the  correlation  pulse. 

As  was  discussed  in  the  introduction,  the  results  presented  here  are  for  a static  antenna  array.  Another 
(and  possibly  more  severe)  set  of  problems  is  introduced  when  dynamics  of  the  signal  source  and/or  array 
weights  are  considered. 

6.  ACKNOWLEDGEMENT 

The  authors  are  indebted  to  Mr.  John  Graniero  of  the  Rome  Air  Development  Center  for  the  experimental 
data  presented  herein. 

REFERENCES 

1.  Berni,  A.  J.,  "Weight  Jitter  Phenomena  in  Adaptive  Array  Control 
Loops",  IEEE  Trans  on  Aerospace  and  Electronic  Systems,  Vol . 

AES-13,  No.  4.  July  1977,  pp  344-354. 

2.  Brennan,  L.  E.,  E.  L,  Pugh  and  I.  S.  Reed,  "Control  Loop  Noise 

in  Adaptive  Array  Antennas",  IEEE  Trans  on  Aerospace  and  Electronic 
Systems,  Vol.  AES-7,  p.  254,  March  1971. 

3.  Compton,  R,  T.,  Jr.,  "Adaptive  Array  in  a Spread-Spectrum  Communication 
System",  Proc,  IEEE,  pp.  289-298,  Vol.  66,  No.  3,  March  1978. 

4.  Dixon,  R.  C.,  Spread  Spectrum  Systems , John  Wiley  and  Sons,  1976. 

5.  Raska,  Edward,  Jr.,  "Effects  of  Antenna  Arrays  on  Broadband  Signals", 

GE-79S  M.  S.  Thesis,  Department  of  Electrical  Engineering,  Air  Force 
Institute  of  Technology,  Wright-Patterson  AFB,  OH  45433, 

6.  Steinberg,  Bernard  D.,  Principles  of  Aperture  and  Array  System  Design, 

John  Wiley  and  Sons,  1976"! 


— 


• 

J 

4 

1 iTT'T  - - - | 

< • 

• I 

13-1 


i 

* 

; 
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ABSTRACT 


A method  for  the  transmitting  of  digitally  encoded  video  signals  at  reduced  bit  rates  is 
discussed.  Such  methods  are  important  in  increasing  the  efficiency  of  a noise-resistant  video 
link  from  airborne  to  ground  stations.  The  algorithm  used  for  bit  rate  reduction  should  be 
consistent  with  simple  implementation  and  adequate  picture  quality,  both  under  noise  and 
noiseless  channel  conditions. 

Described  here  is  a DPCM  coding  algorithm  that  treats  the  information  of  the  quantized 
differences  as  a sequence  within  the  feedback  loop.  In  the  example  discussed,  a bit  rate  of 
1 .5  bits  per  picture  element  (pel)  is  provided  with  fixed-length  words.  Every  other  pel  in  the 
line  is  coded  with  a four-level  and  the  remaining  pels  with  a two-level  quantizer.  Therefore 
the  information  of  every  two  adjacent  pels  is  represented  by  2 + 1 = 3 bits  corresponding  to 
1 .5  bits  per  pel. 

Two-dimensional  prediction  with  three  pels  (adjusted  to  the  coding  scheme)  and  a line- 
to-line  offset  in  use  with  two  quantizers  lead  to  an  exchange  of  quantization  and  prediction 
errors  that  equalizes  the  varying  accuracy  of  the  quantization.  At  any  given  moment 
prediction  and  coding  involve  three  pels  with  the  2-bit  and  one  pel  with  the  1-bit  accuracy. 

The  2-bit  quantizer  is  important  for  the  rendition  of  edges  and  the  1-bit  quantizer  for 
the  low  visibility  of  channel  errors.  By  turning  over  to  two  equal  quantizers  the  bit  rate  can 
easily  be  changed  to  2 or  1 bits  per  pel. 

The  efficiency  at  the  rate  of  1 bit  per  pel  can  be  increased  by  coding  the  central  (or 
target)  area  with  a higher  accuracy  than  the  rest  of  the  picture. 

For  example  each  area  has  the  same  number  of  pels  with  the  accuracies  of  1.5  and  of 
0.5  bits  per  pel.  The  1 .5-bit  DPCM  is  applied  to  the  pels  in  the  centre  and  a 2-bit  DPCM  to 
the  average  of  four  pels  outside. 

Performance  results  are  presented  and  compared  with  the  results  for  hybrid  transform/ 
DPCM  coding,  operating  under  the  same  conditions. 
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BUDOS  - A MULTIPLEX  DATA  BUS  TRANSMISSION  SYSTEM 
S 0derud 

A/S  KONGSBERG  VAPENFABRIKK,  NORWAY 


SUMMARY 

Today's  weapon  platforms  have  been  large  and  complex.  NATO's  recognition  of  this  and  a desire  to 
simplify  the  method  of  interconnecting  all  the  user  interfaces  located  throughout  the  platform  led  to 
the  appointment  of  a NATO  group  with  the  task  to  write  standard  interface  specifications  for  naval 
digital  equipment. 

The  highway  or  serial  date  bus  format  is  appropriate  to  systems  vWiere  data  sources  and  users  are 
distributed.  One  interface  specification  STANAG  4156  and  one  data  transmission  system  BUDOS  under 
development  at  A/S  Kongsberg  VSpenfabrikk  will  fulfill  the  requirement  of  STANAG  4156. 

The  polling/contention  type  format  used  for  this  new  system  will  give  system  advantages  and  the  use  of 
more  then  one  bus  data  channel  will  give  system  redundancy  and  gradual  degradation.  The  new  data  distri- 
bution system  BUDOS  will  go  onboard  coast  guard  vessels  under  construction  in  NORWAY  and  will  be  used 
for  ordinary  point-to-point  addressed  data  and  broadcast  transmission. 
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1 . BACKGROUND  AND  SYSTEM  PHILOSOPHY  FOR  STANAG  4156 

Normal  System  growth  of  diverse  equipment  without  excessive  rewirTng  and  life  time  refit  on  the  weapon 
platform  has  led  to  the  recognition  in  NATO  for  standard  interfaces  to  serial  digital  multiplex  data  bus 
for  network  systems.  The  existing  specification  MIL-STD-1553A  (Aircraft  Internal  Time  Division 
Command/Response  Multiplex  Data  Bus)  and  the  new  STANAG  4156  (Standard  Specification  for  a Asynchronous 
Input/Output  Interface  for  Multiplex  Terminals  on  ship  board  General  Purpose  Data  Bus  Systems)  are  two 
of  these  standard?. 

The  work  in  organizing  STANAG  4VI/6  started  back  in  December  1973  when  NIAG  (Nato  Industrial  Advisory 
Group)  Sub-group  6 was  formed  with  the  task  to  write  standards  for  the  interface  to  naval  digital 
handling  equipment.  Over  the  last  two  years  NIAG  has  prepared  two  digital  interface  standards  STANAG 
4153  for  High  speed  computer  like  point  to  point  interfaces  and  STANAG  4156  for  interface  to  network 
systems.  The  group  early  recognized  there  were  two  modes  of  philosophies  likely  to  be  involved  in 
shipbom  systems,  utilizing  point  to  point  links  and  highway  or  bus  connections.  At  an  early  stage  it 
was  realized  that  a single  interface  should  not  be  optimized  for  these  two  modes. 

In  this  paper  I will  concentrate  on  the  interface  specification  optimized  for  Network  Interface  STANAG 
4156  and  one  bus  system  application. 


1.1  Interface  Location 

The  NIAG  Sub-group  6 started  out  trying  to  define  a complete  bus  or  network  system.  However,  divergent 
requirements  from  relevant  navies  regarding  system  complexity,  levels  of  capacity,  redundancy,  and 
different  grades  of  flexibility,  led  to  the  conclusion  that  the  group  should  concentrate  on  the 
"interface"  to  a network  system.  Only  the  minimum  requirements  for  the  network  system  are  to  be 
specified,  and  the  interface  should  be  simple  as  possible,  also  small  users  must  without  too  much 
complexity  build  their  interface  to  satisfy  the  standard. 

See  Figure  1 INTERFACE  LOCATION. 

The  group  also  recommended  that  an  input  part  should  be  independent  of  an  output  part,  forming  one  total 
data  channel.  Two  users  that  employ  the  same  interface  may  be  directly  interconnected  in  the  absence  of 
a network  by  means  of  a simple  coupling  device. 


1.2  Interface  Alternatives 

Within  the  network  each  message  is  headed  with  a 16  bit  control  word.  The  control  word  will  comprise  of 
information  concerning  message  word  identification,  physical  address,  and  a message  number.  This 
information  is  necessary  in  most  systems  to  address  and  identify  the  subsequent  data. 

It  has  also  been  the  purpose  of  the  standard  to  serve  very  simple  users.  The  control  word  can  in  this 
case  be  added  to  the  data  in  the  terminal  for  an  input  channel  and  stripped  off  in  the  output  channel 
(TYPE  A PROTOCOL).  The  network  system  must  for  such  messages  have  a prior  notice  of  the  address  infor- 
mation. 

More  generally  preferable  for  intelligent  devices  such  as  computers,  the  control  word  will  be  sent 
directly  to  the  users  device,  and  it  is  the  user  devices  responsibility  to  decode  the  control  word  and 
to  respond  as  requested  (TYPE  B PROTOCOL). 

See  Figure  2 INFORMATION  MESSAGE. 


The  NIAG  Sub-group  6 felt  that  an  electrical  interface  must  be  made  of  readily  available  components  and 
the  specified  electrical  interface  must  be  made  according  to  international  recognized  specifications. 
The  CCITT  recommendation  V.ll  is  therefor  specified. 


1.4  Bus  System 

The  STANAG  4156  defines  the  functional  and  electrical  characteri sties  of  a network  synchronous 
input/output  interface  for  use  in  systems  which  are  to  be  interconnected  via  a shipboard  data  network 
system.  The  information  transfer  protocol  is  defined  and  the  requirements  which  the  protocol  and 
interface  characteristics  impose  on  the  multiplex  bus  and  users  system  are  established.  Recommendations 
are  made  concerning  the  physical  characteristics  of  the  interface  relating  to  cables  and  connectors. 

The  network  must  be  transparent  to  the  data  submitted  from  the  different  users,  and  no  data  must  be 
stopped  or  ignored  due  to  deficient  parity  or  other  errors.  The  network  systems  shall  not  "store  and 
forward"  data  on  a message  basis,  and  a propagation  time  of  50  /u  sec.  shall  not  be  exceeded.  The 
network  shall  provide  for  both  source  and  sink  initiation  of  messages  and  both  periodic  and  aperiodic 
transfer.  The  bus  system  shall  transfer  messages  with  a maximum  length  of  512  datawords  consisting  of  17 
bits.  All  bus  systems  shall  be  capable  of  transferring  single  address  data  on  a point-to-point  bilateral 
basis.  Bus  systems  that  optionally  provide  unilateral  transfer  capability  shall  be  able  to  transfer 
source  initiated  messages,  broadcast,  via  a single  step  process  to  any  addressed  sink  or  specified 
groups  of  sinks. 

The  response  time  is  defined  as  the  delay  between  the  initial  request  for  message  transfer  and  the 
arrival  of  the  first  bit  of  the  message  at  the  intended  output  interface.  The  response  time  for  most  bus 
systems  is  variable  and  dependent  on  user  systems  connected,  capacity  and  traffic  load.  It  is  the  system 
designers  reponsibil ity  to  simulate  or  otherwise  ensure  that  the  maximum  and  nominal  response  times  are 
kept  within  acceptable  limits.  As  a guideline  a normal  system  will  for  a 50%  probability  have  a response 
time  of  approximate  200  yu  sec,  increasing  to  1 m.  sec.  at  a 99%  probability. 


2.  BODOS  PRINCIPLE  SYSTEM  LAYOUT 

A/S  Konsgberg  VSpenfabrikk  have  under  development  a Multiplex  Data  Bus  Transmission  System  fulfilling 
the  requirements  of  STANAG  4156  called  BUDOS.  Its  purpose  is  to  replace  the  conventional  point-to-point 
wiring  between  shipbourne  electronic  equipment.  In  BUDOS  information  between  the  users  is  transmitted  on 
cannon  multiplex  bus  cables  which  substantially  reduces  the  number  of  interconnections  and  cabling 
costs.  Compared  with  traditional  point-to-pont  wiring  BUDOS  offers  the  designer  a tool  to  make  a 
distributed  and  modular  system.  Using  a system  as  BUDOS  for  your  communication,  independent  system 
programming  can  take  place  in  the  individual  units  or  between  groups  of  units.  BUDOS  also  offers  the 
system  designers  one  focal  integration  point  to  the  individual  users  facilitating  simplified  unit  test. 
BUDOS  is  designed  to  meet  requirements  of  the  STANAG  4156,  and  all  future  equipment  following  this 
standard  can  be  easily  interfaced. 


2.1  The  Data  Bus 

Figure  3 shows  the  principle  system  layout  of  BUDOS.  The  Data  Bus  consisting  of  one  or  more  coaxial 
cables  are  running  through  the  ship.  Each  cable  comprises  one  or  more  frequency  multiplex  channels,  thus 
allowing  a number  of  simultaneous  connections  between  subsystems.  Each  channel  has  a 3 Mbit  data  rate. 
The  digital  data  transmitted  from  the  users  is  divided  into  channels  using  a frequency  division  multi- 
plex system.  The  channel  frequencies  are  from  30  MHz  upwards  in  10  MHz  steps. 


2.2  Interfacing  Subsystems  to  BUDOS 

The  users  are  interfaced  to  the  data  bus  by  means  of  a multiplex  terminal  (MUX  terminals).  The  MUX 
terminals  are  so  designed  that  a user  has  access  to  every  bus  cable  and  every  channel  on  each  cable. 
Further  the  MUX  terminal  can  handle  as  many  simultaneous  connections  as  there  are  channels  on  the  bus. 
The  user  Interface  is  a half  duplex  interface,  therefore  the  user  can  not  transmit  and  receive 
simultaneously.  Two  users  connnected  to  the  same  MUX  terminal  can  also  communicate,  however,  this 
connection  is  not  a short  cjt  within  the  MUX  terminals,  but  will  use  the  main  bus  channel,  just  like  any 
other  connection  between  users  connected  to  the  different  MUX  terminals. 

The  two  different  Interface  protocol  described  in  the  STANAG  4156  can  be  utilized  with  the  BUUOS-system. 
The  type  A protocol  option  (DATA  ONLY),  data  will  only  be  exchanged  with  the  user,  and  the  bus  system 
will  internally  provide  the  addressing  capability.  Where  type  B protocol  option  (control  and  data)  is 
used,  the  user  can  internally  address  all  other  users  connected  to  the  bus  system,  and  the  sub  system  is 
able  to  exchange  various  types  of  data  messages  with  all  the  other  users. 


2.3  System  Capacity  and  Bit  Rate 


The  maximum  BUOOS  installation  allows  15  MUX  terminals  with  up  to  8 user  interfaces.  BUOOS  is  designed 
to  handle  a bit  rate  of  3 M bit  per  sec.  The  bit  rate  on  the  main  channel  is  identical  to  the  bit  rate 
a*,  the  user  interface.  Other  bit  rates  can  be  accomplished,  but  this  will  require  minor  changes  in  the 
MUX  terminal  hardware.  With  a maximun  of  4 data  channels  a total  of  12  M bit  of  data  can  be  handled  with 
the  BUOOS  system. 


2.4  Data  Bus  Control 

Each  separate  data  channel  is  controlled  by  a channel  controller.  The  task  of  these  controllers  is  to 
offer  channel  access  to  the  users.  In  periods  when  the  channel  is  not  occupied,  the  channel  controller 
asks  each  connected  multiplex  terminal  one  at  a time,  if  one  of  its  associated  user  requires  a channel, 
if  so,  the  multiplex  terminal  starts  to  transmit  on  the  channel.  The  channel  controller  does  not  command 
a multiplex  terminal  to  use  a specific  data  channel,  it  merely  offers  the  channel  for  use. 

The  polling  is  performed  by  transmitting  a special  "poll"  control  word  addressed  to  the  desired 
multiplex  terminal.  Because  polling  is  performed  when  the  data  channel  is  not  occupied  no  separate 
control  line  exists  on  the  data  bus. 

All  channel  controllers  operate  entirely  independent  of  each  other,  and  can  be  located  in  different 
multiplex  terminals.  An  error  in  one  channel  controller  will  only  reduce  the  system  capacity  by  one 
channel . 

The  channel  controller  has  no  knowledge  of  the  information  being  transferred,  is  ignorant  concerning 
message  number,  sink  or  source  addressing  etc.  All  the  channel  controller  has  to  know  is  the  number  of 
multiplex  terminals  implemented,  in  order  to  offer  the  idle  data  channels  to  them. 

The  priority  of  the  multiplex  terminals  is  determined  by  the  polling  sequence  of  the  channel  controller. 
High  priority  multiplex  terminals  are  simply  polled  more  often  than  lower  priority  ones. 


3.  PROTOCOLS  ANO  DATA  EXCHANGE 

All  data  exchanged  is  based  on  messages  consisting  of  17  bit  (16  bit  + parity)  words.  The  maximum 
message  length  is  limited  to  511  data  words  + the  control  word. 

All  messages  consist  of  a single  control  word  or  a control  word  followed  by  one  or  more  data  words.  The 
control  word  contains  message  protocol  information  together  with  user  and  multiplex  address 
Information. 

As  previously  mentioned  two  different  types  of  users  may  be  connected  to  BUDOS,  type  A with  simplified 
protocol  or  type  B with  complete  protocol.  If  the  user  is  a type  A system,  the  control  words  are  pro- 
vided by  the  bus  system  at  transmission  and  removed  at  the  multiplex  terminal  at  receipt  of  a message. 
The  type  B user  is  Itself  responsible  for  providing  necessary  control  words. 

The  type  A and  B users  use  the  same  electrical  interface  to  BUDOS. 


3.1  Word  Format 

A data  word  consists  of  17  bits  (16  data  + 1 parity  bit).  The  least  significant  bit  is  transferred 
first,  the  parity  bit  last.  See  Figure  4,  Data  word  layout. 

Data  words  are  not  decoded  by  the  bus  system. 


3.2  Control  Words 

Figure  5.  shows  the  layout  of  the  control  word.  The  general  layout  of  the  control  word  is  in  accordance 
with  STANAG  4156. 

A.  Multiplex  address. 

The  address  of  a multiplex  terminal  is  specified  with  5 bits.  Each  multiplex  terminal  has  its  own 
address.  The  address  00000  is  reserved  for  broadcast  use  in  accordance  with  STANAG  4156. 

A total  of  31  multiplex  terminals  may  be  addressed. 


B.  User  Address  field. 

The  address  of  the  user  system  is  specified  with  3 bits.  This  address  specifies  1 out  of  8 users 
connected  to  the  multiplex  terminal. 

C.  Message  number  field. 

This  field  with  6 bits  contains  a number  specific  for  the  receiving  user  in  order  to  identify  the 
message. 

This  field  is  not  decoded  by  the  bus  system,  and  has  no  Influence  on  its  operation. 
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U.  Wl-word  identification  bit. 

This  2 bit  field  provides  identification  of  the  control  word  function. 

RR  - Receive  Request  control  word.  (10) 

The  user  that  will  transmit  this  control  word  requests  to  receive  a data  message  indicated  by  the 
message  number  from  the  user  specified  in  the  address  field. 

TR  - Transmit  Request:  (11) 

The  user  that  transmits  this  control  word  requests  to  transmit  a data  message  indicated  by  the 
message  number  to  the  addressed  user. 

DM  - Data  Message  (00) 

If  the  Data  Message  is  transmitted  in  response  to  Receive  Request  control  word  (RR)  the  Data 
Message  control  word  (DM)  indicates  that  the  sequenced  data  word  comprised  a Data  Message 
identified  by  message  number  transmitted  from  the  user  identified  by  the  address  field. 

If  the  data  message  is  sent  as  unilateral  transfer  data,  the  Data  Message  control  word  (DM) 
indicates  that  the  message  identified  by  the  message  number,  is  transmitted  to  the  user  identified 
by  the  address  field. 

If  the  data  message  is  a broadcast  message  the  data  message  control  word  indicates  that  the  sub- 
sequent data  word  comprises  a broadcast  data  message.  This  is  indicated  in  the  first  part  of  the 
address  field. 

E.  A single  odd  parity  bit. 

The  parity  bit  is  not  set,  removed,  or  tested  by  the  bus  system. 


3.3  Broadcast  Control  Word 

In  addition  to  the  ordinary  poipt-to-point  addressing,  BUDOS  includes  a broadcast,  capability.  This  means 
that  data  messages  may  be  transmitted  to  several  users  simultaneously.  Figure  6.  The  broadcast  control 
word  gives  information  concerning  the  different  bits. 

A.  The  MUX  multiplex  address  part  contains  (00000)  to  indicate  a broadcast  data  message. 

This  address  is  decoded  by  all  MUX  terminals,  and  further  processed  by  all  MUX  multiplex  terminals, 
programmed  to  receive  a broadcast  message. 

B.  The  broadcast  address. 

This  is  a subaddress  decoded  by  all  multiplex  terminals  that  are  programmed  to  receive  broadcast 
messages.  The  multiplex  terminals  can  with  this  address  forward  the  message  to  a group  of  connected 
users.  8 different  groups  can  be  selected  from  this  3 bit  address  field,  and  each  group  may  consist 
of  0 to  8 users. 

C.  Message  number  field. 

This  field  contains  numbers  specific  to  the  receiving  user  for  message  identification. 

D.  WI  - word  identification  bit. 

The  WI  bit  (00)  indicates  data  message  control  word. 


3.4  Message  Exchange  Protocol 

There  are  4 different  message  exchange  protocol  that  may  be  used  in  BUDOS.  See  Figure  7. 

Unilateral  source  indicated  point-to-point  transfer. 

Sink  (receiver)  indicated  point-to-point  transfer. 

- Bilateral  source  indicated  point-to-point  transfer.  A mode  where  the  message  transfer  is  mutually 
agreed  upon  by  source  and  sink. 

Source  indicated  broadcast  transfer. 


I 
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3.4.1  Unilateral  Source  Initiated  Point-to-point  Transfer. 

When  a source  user  is  ready  to  transmit  data,  the  source  transmits  a data  control  word  plus  data  to  the 
sink  user  through  the  bus  system.  All  the  timing  and  proper  bus  controlling  will  be  handled  by  the  bus 
system.  The  address  field  in  the  data  message  control  word  is  the  address  of  the  receiver. 

It  must  be  noted  that  this  is  a unilateral  transfer,  and  if  the  addressed  user  is  busy  when  the  data 
arrives  the  data  message  will  be  lost. 

This  is  one  step  data  transfer  and  is  normally  used  only  for  periodic  data  or  when  the  source  is 
notified  through  another  message  from  the  addressed  user  if  the  message  is  correctly  received  and  under- 
stood. 


3.4.2  Sink  Initiated  Point-to-point  Transfer. 

The  sink  initiates  the  transfer  b.,  sending  a Receiver  Request  control  word,  (RR)  that  is  addressed  to 
the  source  system.  The  source  user  responds  with  the  requested  message  which  is  preceded  by  a Data 
Message  Control  word  (DM),  carrying  the  source  address. 

Due  to  the  fact  that  BUDOS  is  a half  duplex  access  system,  no  control  word  address  for  bus  addressing 
is  required  from  the  user  answering  an  "RR"  message.  The  answering  user  of  the  "RR"  uses  the  same  bus 
access  when  sending  the  requested  data  thus  eliminating  the  need  for  calling  the  RR  originator  on  a 
separate  addressed  bus  access  as  would  be  the  case  in  a simplex  system. 

This  two  step  transfer  mode  is  highly  efficient  and  should  be  used  wherever  possible. 

In  response  to  Receiver  Request  the  source  will  transmit  a data  message  control  word  and  data,  back  to 
the  sink.  This  connection  will  be  closed  if  no  Data  Message  is  transmitted  within  50  /u  sec.  after 
receipt  of  the  Receive  Request  word  (RR). 

Typical  application  for  sink  initiated  transfer  are  as  follows: 

The  sink  user  is  requesting  data  from  a simple  user. 

Two  or  more  sink  users  are  requesting  data  independently  from  the  same  source  (sensor).  The  source 
not  interested  in  the  identity  of  each  of  the  sinks,  merely  loads  data  into  registers  which  can  be 
read  out  in  response  to  Receive  Request  from  any  number  of  sinks. 

The  source  is  a bus  orientated  processor  system  and  the  sink  user  can,  in  specific  main  memory 
cells  read  data,  addressed  with  the  message  number.  The  source  device  will  not  be  loaded  with  this 
data  handling. 

3.4.3  Bilateral  Source  Initiated  Point-to-point  Transfer. 

The  source  initiates  transfer  by  sending  a Transmit  Request  control  word  (TR)  that  is  addressed  to 
the  sink  user.  The  sink  user  if  not  busy  will  respond  with  the  Receive  Request. 

The  sink  user  must  respond  within  50  /u  sec.  If  there  is  no  response,  the  source  user  must  send  a 
Transmit  Request  again  at  a later  time. 

When  the  source  user  receives  Recevier  Request  it  should  respond  by  transmitting  the  Data  Message  header 
word  (DM)  followed  by  the  data. 

Note  that  the  Data  Message  address  field  always  carries  the  sink  address. 

As  for  sink  initiated  point-to-point  transfer  the  time  between  the  receipt  of  Receive  Request  and  the 
transmission  of  Data  Message  control  word  (DM)  back  to  the  sink  a maximum  time  of  50  /u  sec.  is  allowed. 

This  is  a 3 step  source  initiated  sequence,  and  should  only  be  used  when  the  preferred  sink  initiated 
mode  can  not  be  used . 

Typical  cases  for  source  initiated  transfers  are  the  following: 

The  source  user  is  transferring  data  to  sink  device  that  does  not  have  the  capability  to  initiate 
the  transfer. 

The  message  is  valid  at  discrete  times  known  only  to  the  source  device. 

The  message  is  transferred  infrequently  but  requires  timely  transfer  thereby  ruling  out  the  possi- 
bility of  low  rate  periodic  requests  from  the  sink. 

The  message  is  being  sent  to  a new  or  unusual  sink  device  and  the  new  sink  device  does  not  know 
that  it  should  request  the  message.  Tnis  will  be  the  case  in  back-up  mode  or  when  operational  mode 
changes  take  place. 


3.4.4  Retransmission. 


There  is  no  automatic  retransmission  capability  built  into  the  bus  system.  User  systems  that  do  not 
receive  data  messages  from  another  user  upon  request,  are  responsible  to  retransmit  the  request 
themselves.  Because  too  many  retransmissions  will  load  the  system  the  following  transmission  procedure 
is  recommended:  Users  should  request  a message  no  more  tr  an  4 times  at  the  minimum  time  interval. 
Subsequent  attempts  to  request  a message  from  *n  unresponsive  user  should  typically  be  at  a rate  of  one 


4.  REDUNDANCY  AND  GRADUAL  DEGRADATION 


BUDOS  has  been  designed  so  that  all  failures  shall  result  in  gradual  degradation  rather  than  a full 
loss  of  the  entire  communication  information  transfer  system.  This  was  also  the  case  in  most  systems 
before  with  dedicated  wires  and  point-to-point  connection.  It  is  vital  that  this  gradual  degradation  is 
also  achieved  with  the  new  data  network. 

If  considered  a prime  controller  and  a back  up  controller  the  system  runs  normally  until  the  prime 
controller  fails.  The  back  up  controller  then  takes  over  and  runs  the  system  at  the  same  capacity  level. 
If  the  back  up  controller  fails,  the  system  totally  fails.  During  normal  operation  you  have  a back  up 
controller  that  only  gives  you  extra  electronics  and  adds  nothing  to  the  system,  idle  redundancy. 

In  BUDOS  the  channel  controller,  one  for  each  channel,  is  distributed  in  the  system.  By  adding  more 
channels  you  are  adding  more  channel  controllers. 

There  is  a trade  off  between  a level  of  redundancy  and  level  of  total  capacity.  With  4 channel 
controllers  and  a sudden  failure  in  one  of  the  controllers  the  system  capacity  will  be  reduced  with  25%. 
With  a loss  of  3 channel  controllers  you  will  still  have  a capacity  of  25%.  No  messages  will  be  dropped 
out,  but  the  system  response  time  will  increase.  Increase  in  response  time  should  be  taken  care  of  in 
the  users  sub  system  and  if  programmed  correctly  should  reduce  the  update  rate  for  the  low  priority 
messages.  If  at  a later  time  in  a vessels  life  cycle  new  sensors  and  new  systems  are  introduced  or  the 
data  load  increases  more  channels  can  be  added  without  any  implementation  or  modifications  to  the  exist- 
ing users  systems. 

In  the  same  way  as  loss  of  channels  will  give  reduced  capacity,  loss  of  bus  cables  will  also,  if  the 
system  is  equipped  with  more  than  one  bus  cable. 


5.  MAINTENANCE 

Previously  in  this  paper  it  was  shown  how  the  channels  are  offered  to  the  different  multiplex  terminals 
through  the  polling  technique.  Any  user  that  has  information  to  be  transmitted  can  when  offered  an  idle 
channel  from  the  multiplex  terminal  use  that  channel.  The  user  has  no  knowledge  of  vrfiich  channel  he  is 
using.  He  will  only  use  the  first  one  which  becomes  idle. 

If  there  is  a break  down  in  one  or  more  of  the  channels  this  will  not  be  known  to  any  of  the  users  if 
they  are  not  given  the  opportunity  to  chose  a specific  channel,  and  check  the  channels  out  one  by  one. 

Going  back  to  an  earlier  statement  concluding  that  a traffic  controller  does  not  command  a user  to  take 
a specific  channel  but  only  offers  the  user  that  channel,  we  can  expand  this  fact.  If  a user  is  given 
the  opportunity  to  see  which  channel  he  is  offered  or  only  recognizes  offers  from  specific  channels  we 
can  then  check  out  all  the  different  channels  and  connections  in  the  BUDOS  system. 

At  each  multiplex  terminal  there  is  one  "special"  user  interface  with  one  extra  interface  line.  This 
difference  gives  a multiplex  system  user  the  capability  of  only  recognizing  offers  from  one  programmed 
channel . 

The  user  normally  a computer  can  act  as  a maintenance  unit  together  with  this  normal  function,  connected 
to  this  specific  user  input  with  this  extra  interface  line. 

The  maintenance  computer  can  request  status  messages  via  Receive  Request  calls  from  all  the  other  differ- 
ent users  on  all  the  different  channels.  This  test  will  detect  errors  in  the  multiplex  terminal  modules, 
in  the  cables,  and  in  the  user  interfaces. 

Since  every  multiplex  terminal  has  this  special  input,  which  can  also  act  as  a standard  user  interface 
to  the  BUDOS  system,  the  maintenance  function  can  also  be  distributed  and  is  not  hung  up  by  single  point 
failure  in  one  maintenance  unit.  It  is  a standard  interface  that  is  used  for  maintenance  function  and 
one  of  the  connecting  computers  can  be  used  to  utilize  this  function  for  very  little  extra  cost. 

The  previously  discussed  maintenance  checking  is  performed  on-line.  During  system  tests  and  in  the  pre- 
installation phase  another  unit  can  be  connected  to  the  BUDOS  system  for  supervision  of  the  total 
message  flow  in  BUDOS. 

Together  with  normal  fault  detection  the  purpose  of  this  unit  is  to  calculate  traffic  statistics  worst 
case  delays,  and  message  utilization. 


6.  PRACTICAL  IMPLEMENTATION  OF  BUDOS  IN  THE  RNON's  COAST  GUARD 
A new  type  of  coast  guard  vessel  is  under  construction  in  Norway. 

The  first  three  vessels  to  be  built  will  be  of  frigate  size  (2800  tons).  The  total  electronic  package  to 
go  onboard  will  be  about  150  units,  and  for  the  data  interchange  between  the  major  units  BUDOS  system 
has  been  selected  in  the  pre-study  phase. 

The  Navigation  and  Command  Control  and  Information  System  NAVKIS  which  is  planned  to  go  onboard  these 
vessels  will  be  connected  to  the  data  bus  system  BUDOS,  as  simplified  in  Figure  8.  Data  Bus  System  for 
NAVKIS. 

As  seen  from  Figure  8 there  will  be  three  MUX  terminals,  and  a total  of  2 cables  used.  To  reduce  the 
single  point  failure  all  units  which  are  not  duplicated  by  other  sensors  are  connected  to  two  multiplex 
terminals.  A total  failure  in  any  MUX  terminal  will  therefore  not  extensively  reduce  the  operation  of 


the  system.  Most  of  the  processors  used  in  the  NAVKIS  system  will  use  A/S  Kongsberg  VApenfabrikk' s new 
data  processing  system,  KS-500,  which  is  a bus  oriented  processing  system.  The  interface  module  to  the 
BUDOS  system  will  be  an  active  module  and  will  collect  and  store  information  directly  in  the  KS-500  main 
memory,  and  will  not  interrupt  the  processors  operational  programme  during  this  function. 

Since  not  all  units  are  delivered  with  interface  according  to  STANAG  4156,  also  in  the  NAVKIS  system, 
interfaces  as  synchro  type  and  20  mA  current  loop  will  be  used.  These  interfaces  will  be  premultiplexed 
and  converted  to  a format  according  to  STANAG  4156  before  being  introduced  to  the  BUDOS  system.  This  pre- 
multiplexing will  not  take  place  in  the  standard  BUDOS  terminal,  but  in  remote  units  or  in  sensor 
cabinets. 

It  is  also  to  be  noticed  that  the  power  has  to  be  distributed  in  the  same  way  as  the  data  and  interfaces 
are  distributed.  In  the  NAVKIS  system  power  will  be  individually  controlled  and  supplied  to  each  of  the 
3 multiplex  units. 

The  total  data  load  for  NAVKIS  system  will  in  the  initial  phase  be  approximately  2 M bit.  The  load  dur- 
ing reprogramming  is  not  taken  into  consideration  in  these  figures.  The  total  4 channel  utilization  will 
be  approximately  2%.  With  only  one  channel  in  operation  the  utilization  will  increase  to  approximately 
8%.  The  response  time  with  50%  probability  with  1 channel  will  be  approximately  35-40  /u  sec.  and  with 
99.9%  utilization  approximately  5.5  msec. 

With  BUDOS  data  transmission  system  the  NAVKIS  project  will  have  an  attractive  data  communication 
system  for  the  future. 


Fig.l  Interface  location 


Fig.2  Information  message 


CC: Channel  Controller 


Communication 


Fig.7  Message  exchange  protocol 


Radar  Extractor 
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DISCUSSION 


M.G.Stainsby 

What  is  the  maximum  number  of  terminals  in  the  BUDOS  system? 

Author’s  Reply 

In  the  present  design  of  BUDOS,  1 5 inputs  to  the  main  bus,  for  each  input  it  is  a mux  terminal  with  8 user  in/outputs 
(as  STANAG  4156).  A total  of  1 20  users  for  one  BUDOS  system. 


M.G.Stainsby 

What  is  the  time  out  period  after  the  controller  has  polled  a given  BUDOS  terminal? 

Author’s  Reply 

The  interword  gap  in  BUDOS  is  3 to  4 bits.  The  minimum  delay  before  polling  the  next  user  will  be  the  interword 
gap  plus  the  cable  delay,  approximately:  (4x1/3  + 1)  microseconds  = 7/3  microseconds. 


ADNET:  AN  EXPERIMENTAL  INFORMATION  DISTRIBUTION  SYSTEM 
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T D Wells  and  M G Stainsby 
Computer  Division 

Admiralty  Surface  Weapons  Establishment 
Portsdown  Cosham 
Portsmouth  Hants 
England 

SUMMARY 

ADNET  (Action  Data  Net)  is  a laboratory-based  feasibility  model  of  a shipbome  command  and  control  system. 
It  is  intended  to  allow  examination  and  solution  of  problems  associated  with  the  introduction  of 
distributed  computing  techniques  to  Naval  systems  in  such  a way  as  to  allow  flexibility  of  major  weapon 
systems  and  reconfigurability  of  command  functions.  This  paper  describes  the  hardware  implementation  of 
the  information  distribution  system  around  which  ADNET  is  based,  and  which  is  in  operation  at  the 
Admiralty  Surface  Weapons  Establishment. 

1.  INTRODUCTION 

The  first  implementations  of  computers  in  the  Royal  Navy,  as  with  other  Navies,  were  based  on  centralised 
architectures.  Few  options  were  available  since  the  choice  was  made  at  a time  when  central  processors 
were  expensive  and  mini-computers  unknown.  This  has  resulted  in  systems  which  are  inflexible  and  difficult 
to  modify;  in  turn  this  exacerbates  the  problems  of  through-life  support.  A ship  with  a hull  life  of 
20  years  can  be  expected  to  benefit  from  significant  weapon  and  sensor  changes  at  least  once  in  its 
lifetime.  In  centralised  command  and  control  systems  such  changes  are  rendered  difficult  by  problems  of 
modification  of  the  large  real-time  control  program  in  the  central  computer,  and  near  impossible  by  the 
difficulties  of  renewing  or  altering  significant  amounts  of  the  cabling  which  runs  from  individual  weapons 
and  sensors  to  the  computer  room. 

ADNET  (Action  Data  Net)  is  a laboratory  model  of  a distributed  command  and  control  system  which  is  being 
used  (iT  to  prove  feasibility  of  an  efficient  solution  to  the  broad  requirements  for  a flexible  and 
modifiable  command  and  control  architecture  (ii)  to  establish  and  resolve  potential  problems  in  assembling 
and  maintaining  such  a structure.  This  paper  is  a description  of  the  inter-computer  communication  highway 
around  which  ADNET  is  based  and  which  is  now  set  to  work  at  ASWE.  Though  not  described  here  in  detail, 
work  is  proceeding  on  top-down  distributed  system  design  and  structured  software  is  being  produced  and 
tested  on  differing  machines  connected  to  the  common  highway. 

When  the  problem  of  specifying  a more  suitable  architecture  was  considered  in  ASWE,  it  was  with  a view  to 
providing  a solution  that  would  allow  more  flexibility  of  the  command  system  and  easier  major  equipment 
modification  than  can  be  obtained  with  centralisation.  It  was  appreciated  that  any  solution  would  have 
to  take  account  of  the  significant  in ter -computer  communication  problem  which  would  arise  from  the 
introduction  of  distributed  processing.  It  was  also  realised  that  information  from  major  sensors  onboard 
ship  is  of  interest  at  a significant  number  of  points  in  the  command  structure,  and  it  was  felt  that  any 
adopted  communication  system  should  have  the  capability  of  efficient  multi-point  distribution. 

The  overall  strategy  advocated  has  been  to  use  a modular  approach  to  software  construction  and  test 
(MASCOT)  which  defines  that  software  should  be  designed  in  terms  of  data  flow  between  processes  through 
formal  interfaces  and  that  synchronisation  should  be  achieved  through  a standard  kernel.  A brief 
description  of  MASCOT  appears  elsewhere  in  these  proceedings  (Gladman  et  al  1978).  Such  kernels  should 
appear  in  each  computer  involved  in  information  dissemination  or  collection  and,  from  an  overall  system 
point  of  view,  it  should  not  matter  whether  or  not  communicating  processes  are  co-located  in  the  same 
computer.  By  implication  the  inter-computer  communication  system  should  be  at  a level  below  application 
software,  and,  as  near  as  possible,  unseen  by  it. 

The  communication  system,  which  has  been  built  is  in  the  form  of  a multidrop  highway,  as  shown  in 
Figure  1,  to  which  all  major  weapon  systems  and  command  positions  on  the  ship  can  connect.  Access  is 
governed  by  a highway  controller  through  a set  of  specialist  message  protocols.  Individual  terminals 
polled  by  the  controller  must  reply  either  with  a data  message  or  a nil  response.  Data  messages  are  not 
addressed  but  are  broadcast  to  all  terminals,  which  accept  or  reject  messages  on  the  basis  of  a content 
descriptor,  or  message  type  byte,  in  the  message  header.  Thus  all  information  is  available  at  all 
terminals  and  facilities  exist  for  users  to  specify  particular  subsets  for  their  own  use. 

2.  HIGHWAY  ARCHITECTURE 

The  highway  consists  of  a single,  overall  screened,  twisted  pair  cable,  terminated  at  each  end  by  its 
characteristic  impedance.  Connections  from  it  are  by  means  of  high  impedance  transformers  at  the 
end  of  short  spurs.  To  reduce  vulnerability,  where  a terminal  remote  from  the  main  highway  is  required, 
it  may  be  connected  by  an  active  bi-directional  spur,  as  shown  in  Figure  2. 

The  highway  is  built  to  interconnect  distributed  computers  and,  to  achieve  this,  dedicated  'front-end' 
communication  processors  are  used  as  terminals.  These  terminals  have  DMA  capability  to  a limited  part  of 
their  host  computer's  memory,  as  shown  in  Figure  3.  The  host  computer  may  initialise,  start  or  stop  a 
terminal,  as  well  as  specify  the  message  types  that  it  wishes  to  receive  from  the  highway.  Line 
signalling,  interpretation  of  protocols  and  error  recovery  are  handled  by  the  terminals  and  are  invisible 
to  the  host  computer.  The  terminals  are  specialist  8-bit  processors,  built  around  AMD  2901  bit-slice 
microprocessors  and  controlled  by  32-bit  wide  microcode. 
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3,  LINE  SIGNALLING 

Screened  twisted  pair  cable  and  fully  balanced  driving  are  used  to  give  noise  immunity.  The  cable  used 
is  URM-68,  with  measured  sine-wave  attenuation  as  shown  in  Figure  4.  The  terminals  in  use  have  been 
built  with  options  to  allow  their  configuration  in  a regenerative  loop  as  shown  in  Figure  5,  but  all 
experiments  to  date  have  been  conducted  under  multidrop  working,  and  it  is  currently  envisaged  that  it 
will  be  feasible  to  specify  a ship  system  in  this  way. 

The  chosen  modulation  scheme  is  shown  in  Figure  6(a)  and,  though  it  is  known  in  literature  by  a variety 
of  names,  is  referred  to  in  this  application  as  Frequency  Modulation  or  FM  coding.  The  more  widely  used 
Manchester  Coding  waveform  is  shown  in  Figure  6(b)  for  comparison.  Although  the  Manchester  version  gives 
slightly  better  performance  against  gaussian  noise,  the  final  choice  of  FM  coding  was  based  on  the 
purely  pragmatic  grounds  that  it  is  insensitive  to  inversion  of  the  2 conductors  during  connector 
assembly.  The  FM  coding  of  Figure  6(a)  is  violated  only  once,  as  shown  in  Figure  6(c),  to  give  a unique 
end  of  message  code.  Line  signalling  rate  is  3 Mbits/sec. 

4.  MESSAGE  STRUCTURES 

The  highway  operates  by  means  of  a formal  set  of  message  structures  as  shown  in  Figure  7.  Each  field  is 
8 bits  long  with  the  exceptions  of  SOM  (16  bits)  and  DATA  which  is  a multiple  of  8 bits  up  to  248  bits 

total.  Consider  Message  7.1  ie  a 'permission  to  transmit'  message.  The  key  to  the  structure  of  this  is 

as  follows: 

SOM  This  is  a start  of  message  flag  and  includes  synchronisation  bits. 

UMN  'Use  Message  Number'  Issued  by  the  controller.  This  will  become  the  transmit  message 
number  when  a terminal  responds  with  a data  message. 

HCB  'Hardware  Control  Byte’  decoded  by  the  receiving  terminal  to  become  'permission  to 

transmit'  at  a specific  element  on  the  ring.  The  top  bit  of  this  byte  being  set  to  zero 

indicates  that  no  data  message  follows. 

ECB  'Error  Check  Byte'  to  allow  a cyclic  sum  check  to  be  performed. 

EOM  'End  of  Message'.  This  is  a violation  of  normal  coding  rules  thus  allowing  all  data 
codes  to  be  transmitted. 

In  figure  7.2,  a 'short  message'  transmission  in  response  to  a 'permission  to  transmit'  is  construed  as 
follows : 


SOM,  ECB,  EOM  are  as  above. 

NAK  Is  an  acknowledgement  that  the  transmitting  terminal  has  received  correctly  all  message 
numbers  up  to  NAK.  Thus  if  NAK  = (UKW-1)  all  previous  messages  have  been  correctly 
received  at  that  terminal.  If  NAK<(UMN-1)  then  the  highway  controller  will  issue  a 
repeat  of  the  message  ie  NAK  when  it  next  has  control  of  the  highway. 

HCB  Is  as  before  and  returns  control  to  the  highway  controllers,  save  that  the  most 
significant  bit  being  set  to  one  indicates  that  a data  message  follows. 

TW  'Transmit  Message  Number'  is  associated  with  the  current  data  transmission,  and  is 
derived  from  the  UMN  of  the  'permission  to  transmit'  message. 

MTB  'Message  Type  Byte'  is  designated  by  software  at  the  transmitting  terminal  and  precedes 
the  data  content  of  any  message. 

DATA  Contains  the  message  and  may  be  of  up  to  248  bits  long. 

In  similar  fashion  to  the  above.  Message  7,3  is  a reply  from  a data  terminal  with  nothing  to  transmit. 

5.  HIGHWAY  OPERATION 

In  normal  working,  the  controller  polls  a terminal  granting  it  "permission  to  transmit".  The  terminal 
responds,  either  by  issuing  a message  which  was  awaiting  transmission,  or  by  sending  a short  "nothing  to 
transmit"  response.  If  the  controller  receives  eitherof  these  responses  without  error  a "permission  to 
transmit"  is  directed  at  another  terminal  and  the  cycle  continues.  If  the  reply  message  from  a terminal 
contains  an  error,  the  controller  re-polls  that  terminal.  (Immediate  re-poll  to  a terminal  which  has 
just  transmitted  is  interpreted  by  that  terminal  as  a request  for  a repeat  of  its  last  message) . The 
controller  will  try  up  to  4 times  to  obtain  an  error-free  response  from  a terminal;  repeated  receipt  of 
errors  from  a particular  terminal  will  cause  the  highway  controller  to  flag  a fault  condition. 

In  normal  operation  terminal  responses  will  be  error-free  and  each  of  the  other  terminals  on  the  line  will 
read  each  response  and  select  or  reject  it  according  to  the  message-type  byte.  A wanted  message  is  only 
validated  at  each  terminal  after  that  terminal  has  performed  its  own  cyclic  sum  check.  A copy  of  each 
message  is,  however,  stored  by  the  controller  in  a 'short  term'  message  store  to  allow  for  the  possibility 
that  although  the  controller  may  have  received  a correct  version,  some  terminals  may  have  detected  errors, 
perhaps  because  of  local  noise.  In  the  event  that  a particular  terminals  response  to  a "permission  to 
transmit”  indicates  that  it  has  received  a previous  message  in  error  (ie  its  NAK  counter  is  not  at  the 
current  UM4  value)  the  controller  will  issue  a repeat  of  the  required  message  from  its  short  term  store. 
Two  further  points  are  relevant  to  a complete  appreciation  of  this  procedure. 
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(a)  It  is  not  necessary  to  repeat  all  messages  between  the  requested  number  and  the  current 
message  number  as  terminals  can  continue  to  receive,  even  when  a correct  copy  of  a previous  message  has 
not  been  obtained. 

(b)  The  message  number  handling  and  repeat  procedures  are  functions  of  the  controller  and 
terminals  only  and  are  unseen  by  application  software. 

6.  SOFTWARE  INTERFACE 

The  host  computer  may  initialise,  start  or  stop  a terminal  by  means  of  relevant  peripheral  control 
functions.  Thereafter  control  and  message  input  and  output  proceed  through  mutually  accessed  software 
tables  such  as  shown  in  Figure  8(a)  and  (b) . Message  selection  is  controlled  by  the  setting  of  individual 
bits  in  the  message  type  byte  table,  which  forms  part  of  the  primary  table,  shown  in  Figure  8(a).  Setting 
of  separate  status  masks  for  control  of  transmission  and  reception  dictates  the  frequency  with  which  the 
host  computer  should  be  interrupted. 

Message  flow  in  and  out  of  host  computer  store  is  controlled  by  the  input  and  output  secondary  tables  of 
Figure  8(b).  Thus  a terminal  which  has  been  granted  permission  to  transmit  must  check  for  the  existence 
of  a message  in  the  next  entry  position  in  the  output  secondary  table,  while  on  reception  the  line 
terminal  will  store  the  next  incoming  message  at  the  location  indicated  in  the  next  position  in  the  input 
secondary  table.  A host  computer  is  expected  to  be  aware  of  the  state  of  the  input  secondary  table  and 
to  ensure  that  locations  for  incoming  messages  are  continuously  available. 

7.  HIGHWAY  CONTROLLER 

Although  it  has  a unique  function  within  an  ADNET  system,  the  highway  controller  consists  of  identical 
hardware  to  the  terminal  boards,  but  with  different  microcode.  In  principle  its  reliance  on  a host 
computer  is  near  zero  and  its  function  can  be  realised,  in  the  existing  design,  with  about  SK  of  random 
access  memory  and  10  words  of  read  only  memory.  However  much  useful  monitoring  information  about  the 
state  of  the  highway  is  available  from  status  tables  and  the  full  benefits  of  this  can  more  easily  be 
realised  by  the  use  of  a host  processor.  With  this  it  is  possible: 

(a)  To  obtain  short  and  long  term  history  information  about  the  performance  of  each  terminal 
on  the  highway,  both  as  a transmitter  and  also  as  a receiver. 

(b)  To  alter  dynamically  both  the  order  and  frequency  with  which  terminals  are  polled,  either 
as  a function  of  varying  traffic  loads  or  in  response  to  some  defined  state  requiring  high  priority  access 
to  be  granted  to  particular  terminals. 

(c)  To  exclude  completely  from  highway  access  a terminal  which  is  responding  unreliably  or 
unintelligibly. 

(d)  To  raise  an  operator  alert,  when  a malfunction  such  as  in  (c)  occurs. 

In  many  applications  the  central  processor  load  in  any  host  computer  associated  with  the  controller  will 
be  light,  and  the  t as k can  be  achieved  by  the  installation  of  a second  interface  in  a computer  that 
already  has  a terminal.  Maintenance  of  the  control  function  is  essential  for  successful  operation  of  the 
highway  and  its  continuance  must  be  assured  for  shipbome  use. 

8.  DISCUSSION 

The  foregoing  description  refers  to  the  ADNET  inter  computer  communication  system  that  has  been  built  and 

working  within  ASWE  for  about  a year.  In  the  sense  that  the  initial  aim  of  the  system  (ie  reliable 

multipoint  distribution)  has  been  achieved  the  experiment  has  been  a success.  Early  integration  with 
distributed  software  is  suggesting  ways  in  which  improvements  can  be  effected,  and  at  this  point  the  basic 
concepts  under  which  this  was  developed  are  being  re-examined.  This  is  possible  because  of  the  tremendous 
flexibility  provided  by  the  microcoded  terminal  processors,  which  means  that  the  cost  of  implementation  of 
a totally  new  set  of  highway  message  structures  will  be  low  - of  the  order  of  8 man-weeks  to  produce  the 
microcode,  and  perhaps  another  6 to  prove  it.  Thus  it  is  possible  seriously  to  consider: 

(a)  The  introduction  of  'block  message  working'. 

(b)  The  introduction  of  more  elaborate  short  message  protocols  better  suited  to  the  software 

structures  of  real-time  distributed  processing. 

(c)  The  operation  of  the  highway  in  contention  mode  ie  without  a highway  controller. 

The  implications  of  these  will  be  briefly  discussed. 

(1)  Block  Message  Working 

This  facility  was  intended  for  inclusion  in  the  original  implementation.  This  will  allow 
the  transfer  of  data  files,  or  program,  along  the  highway  on  a point  to  point  basis.  Messages  will  be  up 
to  256  bytes  long  and  it  is  intended  that  they  will  be  preceded  by  an  acknowledgement  from  the  proposed 
destination  that  it  can  accept  the  information. 
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(2)  More  Elaborate  Protocols 

It  is  envisaged  that  this  highway  will  be  used  in  a situation  where  certain  tasks  and 
functions  are  potentially  migratory  between  differing  physical  locations.  The  totally  broadcast  method 
of  working  is  suited  to  this  environment,  but  it  is  felt  there  could  also  be  advantages  in  retaining 
some  physical  addressing  capability.  Thus  consideration  is  being  given  to  the  adoption  of  the  message 
slh’ucture  shown  in  Figure  9.  Here  'Destination  1'  and  'Source  1'  are  physical  addresses,  the  latter  being 
appended  by  the  transmitting  terminal.  'Destination  1'  being  set  to  zero  would  allow  broadcast  working  as 
in  the  initial  implementation,  while  at  the  other  extreme,  use  of  both  source  and  both  destination  fields 
permits  unambiguous  point  to  point  working  between  software  processes  in  differing  machines. 

(3)  Contention  Working 

The  adopted  poll  and  response  method  of  highway  access  control  gives  some  delays  between 
message  generations  and  transmission.  Simulation  shows  these  to  be  tolerable  up  to  line  loadings  of  the 
order  of  65%.  (In  a cyclically  polled  32  terminal  system  the  average  access  delay  will  be  of  the  order 
of  1 ms).  It  is  recognised  that  these  delays  can  be  reduced  by  the  adoption  of  a contention  strategy 
such  as  in  Ethernet  (1)  with  a resulting  increase  in  potentially  available  useful  message  transmission 
time  due  to  the  absence  of  polling  messages.  However  the  penalties  to  be  borne,  if  contention  working  is 
used,  are  the  lack  of  easy  automatic  error  recovery  and  the  inability  to  locate  easily  a defective 
terminal.  It  is  believed  that  a maintainable  and  reliable  ship  system  will  be  more  easily  achieved  under 
a poll  and  response  technique  than  in  contention  working. 
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MODIFIED  DATA  MESSAGE  FORMAT 


Figure  9 


DISCUSSION 

Kaltschmidt 

I would  like  you  to  explain  two  phrases  on  one  of  your  slides:  High  EMC  Environment;  fibre  optics  not  suitable. 
Normally  one  thinks  of  using  fibre-optical  buses  when  the  EMC  problem  is  very  serious. 

Author’s  Reply 

I would  be  pleased  to  use  a fibre-optic  highway  when  the  technology  to  build  a multidrop  highway  in  fibre  optics 
becomes  possible.  At  present  the  loss  in  a fibre-optic  top  is  too  high. 

Rupprecht 

Did  you  use  any  equalisers  for  your  cables? 

Author’s  Reply 

No.  You  never  know  how  far  away  the  terminal  you  are  trying  to  receive  from  is.  For  a given  point-to-point  link 
you  can  build  an  equaliser  with  no  problem.  For  differing  distances  you  would  require  an  adaptive  equaliser. 

We  chose  to  try  to  improve  our  signal-to-noise  ratios. 
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ABSTRACT 

Structured  design  principles  have  been  used  in  the  formulation  of  a methodology 
for  systems  design  and  applied  to  the  definition  of  avionics  processing 
architectures.  The  task  is  an  effort  to  take  advantage  of  technology  advances  in  the 
computer  field  and  structured  support  in  software  to  reduce  life  cycle  costs  of 
avionics.  A core  avionics  is  defined  and  the  design  constraint  imposed  upon  it 
discussed.  The  structured  procedure  and  the  way  in  which  it  is  meant  to  take 
advantage  of  technology  is  explained.  Impact  of  standard  is  presented  and  c specified 
scheme  for  implementation.  Alternatives  for  development  and  acquisition  methods  and 
contracting  for  a generic  avionics  core  are  presented. 

In  t roduc  t ion 


Structured  design  is  a top  down  procedure  which  results  in  a near  optimum  software 
implementation  of  a set  of  performance  traded  functions.  Optimum  is  primarily 
considered  to  be  economic  with  performance  and  maintainability  features  traded.  In 
general,  it  can  be  by  any  measure,  since  the  design  begins  with  a selection  of 
pr i or i t i t i zed  design  criterion  particular  to  the  system  such  as  A/C  avionics . Traded 
functions  refer  to  subsystem  and  system  mode  functions  along  with  their  algorithms  for 
the  most  part  which  are  bounded,  optimized  and  traded  off  to  some  performance  measure 
as  might  be  done  in  researching  tracking  or  detection  algorithms.  Since  avionic 
systems  can  represent  a set  of  defined  and  bounded  functions  within  a mission  and  are 
normally  designed  to  strict  constraints  and  criterion,  they  can  lend  themselves  to 
implementation  via  a more  structured  approach  than  has  been  used  in  the  past,  and 
which  may  be  possible  in  larger  less  constrained  systems.  It  is  somewhat  of  a marked 
departure  from  previous  integration  procedures.  Most  past  design  philosophies  avoid 
the  risk  of  advanced  technology  in  favor  of  low  risk  integration  of  present  technology 
which  has  resulted  in  unique  and  complex  integration  configurations  and  associated 
high  costs.  The  definitions  herein  and  the  structured  engineering  procedure  suggested 
serve  as  an  introduction  to  a unified  approach  to  system  design  utilizing  common 
architectural  concepts,  interfaces,  and  new  technologies  which  used  effectively  can 
achieve  lower  life  cycle  cost  in  future  avionics.  It  represents  a wider  application 
of  structured  design  than  its  original  software  programming  intent  but  with  similar 
objectives.  Some  history  may  clarify  the  motivation  in  light  of  the  economics  of 
complex  weapon  system  acquisition  existing  today.  The  first  figure  is  an  illustration 
of  the  evolution  of  avionics  system  implementation  over  three  decades.  In  regard  to 
processing  of  both  data  and  signals  in  the  1950's,  and  prior,  we  saw  independent  self 
supporting  subsystems  competitively  procured  and  installed  with  very  little 
intra-subsystem  data  flow.  Each  major  subsystem  usually  required  an  independent 
operator  console  and  interface.  Only  obvious  interfaces  and  data  transfer  occurred. 
As  computers  entered  the  scene,  their  primary  use  was  in  heavy  computational  modes  as 
navigation  and  autopilot  systems,  and  then  on  into  sensor  subsystems  and  into  signal 
processing  computations.  The  1960's  evolved  the  software  packages  sucli  that 
generalized  computations  for  all  subsystems  moved  into  multiplexed  centralized 
computers  with  both  non-real  time  and  real  time  interfaces.  This  was  an  effort  to 
save  the  cost,  weight,  and  size  of  computer  hardware  and  consolidate  computer  program 
and  data  handling.  However,  because  of  mode  expansion  it  generated  a cost  growth 
problem  in  complex  software  generation  and  software  support,  particularly  when  within 
the  same  system  different  manufacturers'  computers  were  used,  it  required  use  of 
multiple  languages,  various  software  interconnect  schemes,  software  support  systems,  and 
software  maintenance  tools.  Avionic  systems  are  not  alone  in  this  evolution,  but  feel 
the  impact  of  the  problem  to  a greater  degree  when  both  mission  and  subsystem 
functions  are  expanded.  The  technology  advances  experienced  in  the  70's  show  trends 
toward  reversing  this  evolution  due  to  the  availability  of  small,  inexpensive,  low 
power,  light  weight  processors  capable  of  meeting  95%  of  the  speed  requirements  and 
offering  a host  of  advantages  very  appropriate  to  avioncis.  Designs  cannot  return  to 
complete  independence,  since  this  same  period  has  seen  the  growth  of  intra- subsystem 
dependence  and  real  time  interfaces  for  data  and  signal  correlation,  and  assimilation, 
and  the  resulting  increase  in  subsystem  communications.  For  example,  the  operational 
program  in  the  P-3C  alone  has  grown  by  35%  in  one  decade  primarily  due  to  expansion  of 
sensor  subsystem  modes.  Figure  2 is  an  example  of  central  computer  usage  where  data 
from  all  subsystems  is  assimilated,  even  though  signal  processors  are  used  in  each 
subsystem.  When  computing  power  is  added  by  adding  addit’onal  processors  to  pick  up 
expanded  modes  the  usual  circumstances  is  introduction  of  additional  software  support 
schemes,  problems  in  data  communication,  I/O  compatibility,  program  and  data  linking, 
protocol,  etc,  making  programming  debugging  and  running  difficult  and  expensive,  v th 
logistics  and  maintenance  poor.  However,  this  is  primarily  because  a program 
structure  is  unique  and  difficult  to  modify  without  great  expense  and  complex  control 
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schemes.  Several  technology  advances  within  this  decade  now  allow  us  to  tailor 

processing  resources  to  the  various  tasks  rather  than  to  determine  as  best  we  can  what 
will  fit  into  available  resources,  allowing  for  planned  reserve  and  expansion,  without 
cost  growth.  In  the  list  of  major  advances  we  n.ust  include  LSI  microprocessors, 
microprogramming  techniques,  advances  technology  memory  devices,  CCD  functional 
hardware,  soft  v.  are  interface  and  macro  techniques,  II OL  deficiency  improvements, 
techniques  for  human  function  automation,  self  diagnostics,  and  especially  the 

techniques  for  distributing  computer  resources  and  distributing  processes  by  shared  or 
dedicated  processing  units  or  memory  and  the  ab'lity  to  use  in  these  networks 
functional  module  hardware. 

Our  goal  is  to  arrive  at  a procedure  for  avionics  design  by  which  we  can  combine 

the  aspects  of  a structured  design,  with  the  advantages  of  the  techniques  of 

implementation  in  advanced  technology  while  incorporating  concepts  of  distributing 
computer  resources.  Lets  begin  by  looking  at  the  characteristics  of  all  these  areas 
and  then  to  their  marriage  via  a design  procedure  guided  by  system  constraints.  This 

marriage  is  the  essence  of  the  procedure  and  the  means  by  which  we  can  implement  the 

improvements  in  avionics,  at  each  level  and  combined  levels  of  functional  modularity, 
e.g.,  system  subsystem,  mode  in  subsystem,  function  or  mission. 

Characteristics  of  Structured  Design 

Fundamental  to  a structured  design  is  the  breaking  up,  partitioning  or 
decomposition  of  system  functions  into  separated  modules.  Modularization  has  been 
defined  as  the  decomposition  of  large  functions  into  small  functions  in  an  organized 
manner.  In  the  software  structure,  modularity  is  used  to  invoke  convent ;ons  in 

programming  techniques  and  standard  interfaced  of  program  segments  to  make  coding, 

control,  debugging,  expansion  and  maintenance  easier  and  less  costly.  Characteristics 
of  a structured  design  therefore  are  (figure  3): 

1.  A method  of  decomposition  into  modules  of  system  functions. 

2.  Imposition  of  standards. 

3.  Methods  of  structuring  segmented  functions. 

4.  A design  criterion  for  selection  of  standards  and  module  interfaces. 

In  addition,  in  applying  the  procedure  to  not  only  software  but  hard v; are  and 
firmware  we  require  as  new  technology  might  dictate: 

1.  Allocation  criterion  for  hardware/sof tware/f irmware. 

2.  Hardware  interface  definitions. 

3.  Procedure  for  incorporating  constraints  of  the  system  which  influence  the 

above . 

4.  Relationships  in  a language  to  firmware/hardware  modules. 

Modularity  of  this  nature  brings  with  it  several  significant  advantages  in  design 
which  relate  diiectly  to  system  improvements  and  can  form  inputs  to  our  list  of  design 
criterion.  Some  advantages  (figure  4)  are  ease  of  modification,  multiple  use  of 
modules  (transportability),  simplified  structured  programming,  simplification  of 
software  by  hardware  instructions  which  reduce  program  complexity,  increased 
reliability. 

In  relation  to  avionics  design  modularity  can  be  defined  functionally,  or  in 

relation  to  subsystems  or  mission.  This  is  illustrated  in  the  matrix  shown  as  figure 
5 of  subsystem/function  breakdown.  Another  way  of  looking  at  a top  level  is  to 

associate  subsystems  and  functions  relative  to  the  primary  mission  which  they  perform, 
ASW,  AE W,  TACA1R  surveillance,  etc,  vs  functions  of  the  mission.  A generic  way  of 
forming  avionics  modules  is  to  consider  mission  independent  functions  and  subsystems 
(the  consistent  intersection  of  the  mission  and  subsystem  matrices)  of  core  avionics 
on  which  to  build  a variety  of  mission  responsive  systems.  Core  avionics  include; 

Navigation 
Communications 

Info/Data/signal  Processing  Architectures 
Flight  Control 
Flight  Instruments 
Displays/Controls 
Electrical  Powc  r 
Fue ling  Sy  s tern 
Stores  System 

The  avionics  information  processing  architecture  is  the  means  by  which  core  and 
mission  particular  avionics  are  interfaced  via  a networking  of  component  resources, 
data/signal  distribution  and  control  methodology,  using  standard  interfaces,  and 
protocols.  Our  process  goal  is  to  decompose  toward  modules  at  lower  levels 
imp  1 emeu  tab le  in  single  form,  interconnected  to  form  sub s y s tern/ sy s t em  functions.  The 
impact  of  this  decomposition  is  seen  mostly  in  installation,  configuration,  software 


and  maintenance  costs . The  lowest  level  of  module  is  the  microcoded  function  in  a 
form  allocated  to  hardware  firmware  or  software  control.  The  decomposition  occurs 
primarily  in  subsystems  but  intra/subsystem  and  tactical  functions  are  of  importance 
to  successful  system  implementation.  The  partitioning  of  core  and  mission  functions 
serves  to  define  the  role  of  processing  architecture  and  processor  interconnect 
network.  A new  different  techniques  for  function  decomposi tion  have  been  developed 
which  can  apply  to  the  avionics  process  in  line  with  a design  criterion.  We  first 
list  such  criterion  and  typical  avionics  characteristics  and  constraints.  A criterion 
(figure  6)  can  be  formed  in  several  aspects  of  the  design,  software,  maintenance, 
modularity  and  core  system  definition,  hardware,  etc. 

Wherever  possible  simplify  software  implementation  and  support 

Consider  language  standards 

Software  interface  standards 

Replacement  by  functional  hardware/ firmware 
Partitioning  of  executive  functions 
Provide  portability  of  software 

Consolidate  support  software  and  configuration  management 
Incorporate  self  diagnostics 
Incorporate  complete  fault  isolation 
Provide  30Z  growth  in  functional  expansion 
Design  20%  reserve  in  resources 
Reduce  weight  25% 

Automate  all  mundane  operator  functions 
Warranty  provisions 
Design  with  minimum  count 
Design  for  minimum  operator  interfaces 

Design  degraded  modes  with  automated  recovery  responses 
Design  for  minimum  intra  subsystem  communications 
Design  flexibility  in  processor  allocation 
Design  adaptability  of  specified  functions 

Design  portability  of  software  to  new  technology  hardware 
Design  recovery  modes  as  opposed  to  redundant  modes  or  vice  versa 
cold  3tandby  - radar,  acoustics,  etc 
warm  standby  - communications,  navigation 
Caust  modes  (command,  control) 
memory  sharing 

back  up  programs  for  reduced  modes 
redundant  power  sources 
Error  detection/checking/correction 

Establish  product  improvement  categories  and  lines 

Establish  standard  hardware  interfaces  between  subsystem  in  A/C  particularly 

Radar 
Sonar 
MAD 

Optics 

Provide  automatic  prompting  of  crew  in  flight  control  and  mission  operations 
Provide  appropriate  criterion  for  design  of  each  subsystem 
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Typical  avionics  constraints  are  listed  as  mission  sensitive  parameters  which  must  be 
addressed  in  selection  of  both  core  and  mission  subsystem  design  and  directly 
influence  the  design  features  in  the  processing  architecture.  For  example,  in  an  ASW 
mission  (figure  7 ) : 

. Real  time  processing  and  real  time  interfaces 

. Dynamic  correlation  between  sensor  system  data,  radar,  acoustics,  navigation, 
magnetics,  optical-IR,  for  tracking,  update,  fixing 

. Processor  and  memory  requirements  are  bounded  and  generally  non  volatile 

. Physical  weight  characteristic  limitations 

. Power  consumption  limitations 

. EMI  requirements 

. Heat/air  conditioning  requirements 

Re  lilability  MTBF 

NTTR  requirements 

. ILS  limitations  - life  cycle  support  time  (20  yrs) 

. Processor  speed  requirements 
. Memory  size  requirements 
. Data  transfer  rates 
. Cost  limitations 

. Maintenance  environment  limitations 

. Prioritization  of  computer  resource  uses  and  subsystem  interface  data,  degraded 
inode  priority 

Commun i c a t i on 

Navigation 

Radar 

. Risk  thresholds  for  each  mode 

. Autonomous  radar  operation  and  navigation  operation 

In  applying  a decomposition  or  partitioning  of  function  for  implementation,  the 
techniques  used  must  be  in  accord  with  the  composite  intent  of  these  constraints  and 
criterion  and  allow  for  incorporation  of  priorities. 

Decomposition  Methods 

Techniques  for  decomposition  have  been  primarily  developed  for  software  program 
segmenting  with  the  objective  of  program  interface  simplification  and  convention 
(figure  8).  Different  techniques  will  result  in  different  modularity  at  the 
implementation  level  and  can  result  in  different  recommended  structure  of  programs  or 
computer  networks  and  media.  Work  at  Carne gi e-Me 1 Ion  University  (reference  (a))  was 
directed  at  a technique  which  maximizes  the  independence  of  program  modules  with  well 
defined  interfaces  for  the  purpose  of  reducing  programming  effort.  It  addresses  the 
methods  of  handling  data  and  program  in  parallel  or  sequentially  and  may  or  may  not 
result  in  modules  which  resemble  steps  in  the  functional  algorithm  process  or  steps  in 
the  computation  in  a signal  data  or  decision  flow  chart.  Thus  it  addresses  software 
programming  on  a general  purpose  device,  and  does  not  directly  pursue  modularity  for 
the  coupling  of  hardware,  software,  and  firmware  in  one  composite  implementation;  nor 
for  embodying  real  time  signal  flow  sequences  as  would  be  programmed  for  signal 
processing  by  signal  processor  designers.  For  our  tactical  processor  implementation 
in  avionics  environment  it  is  desirable  and  to  our  advantage  to  associate  the 
partitioned  elements  in  a manner  as  to  directly  support  efficient  running  of  the 
functional  process.  The  process  being  a completely  executable  entity  embodied  either 
in  hardware,  software  and/or  firmware  segments  whichever  serves  its  needs  best  to 
fulfill  the  criterion  imposed.  Univac  under  Navy  sponsors!)  ip  has  been  pursuing  such 
decomposition  techniques  based  upon  functional  dependence  in  data  flow  and  control  and 
upon  sequential  or  parallel  execution,  priority,  shared  resource,  timing  to  result  in 
a structure  of  elements  which  can  be  appropriately  mapped  into  the  three  medic  and 
permitting  the  development  of  a library  of  many  stand  alone  functions  which  ccn 
satisfy  several  applications  in  avionics  subsystems  and  to  tactical  functions.  After 
decomposition  into  elements,  a dependency  structure  is  generated  which  allows 
assessment  of  implementation  media  and  the  most  economical  networking  of  resources  for 
implementation  when  again  coupled  with  the  design  constraints  of  the  system.  It  also 
structures  the  control  mechanism  for  resources  and  therefore  outlines  executive 
design.  When  functional  elements  require  the  same  resources  (memory,  operation, 
control)  we  can  well  arrive  at  a networking  which  resembles  present  multiplexed 
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programming.  When  unique  and  independent  elements  emerge  they  may  be  implemented  in  a 
distributed  manner  where  the  data  and  resource  requirements  are  met.  This  brings  us 
to  the  step  in  the  partition  process  of  a decision  whether  to  implement  a functional 
segment  in  hardware,  software  or  firmware.  A list  of  a medium  advantage  is  shown  in 
figure  9.  Criterion  by  which  the  assignment  is  made  is  indicated  in  figure  10. 
Firmware  is  a means  of  implementing  partit'onal  programs  in  a rigid  manner  by 
permanently  burning  in  ROM  or  semi  permanently  in  PROM  or  EAROM.  It  may  require  more 
steps  than  software  to  implement  or  less  instructions  to  actuate.  It  therefore  is  not 
as  readily  adaptable  or  modifiable  as  software,  but  can  serve  as  a simplification  to 
overall  programming  when  acting  as  a primitive  macro  or  implemented  subroutine.  In 
this  manner  it  approaches  the  performance  of  hardware  compromising  the  flexibility  of 
software.  Its  reliability  is  a function  of  the  programming  conventions  used  and  the 
quality  control  exercised.  For  the  above  reasons  firmware  implemented  using  LSI 
microprocessor  technology  lias  become  popular  for  embedded  function  replacement  acting 
as  hardware , yet  adaptable  upon  ROM  replacement.  If  we  look  at  the  typical  ways  in 
which  microprocessors  are  used  in  avionics  we  see  a range  from  functional  replacement 
as  program  implementation,  or  data  traffic  control  to  small  scale  progammable 
processor  implementation  with  mic rop rogammed  instructions.  The  latter  replacement 
done  primarily  to  lower  cost.  An  example  of  this  application  in  avionics  (for 
communications  control)  is  shown  in  figure  11,  where  logic  sv/itching  of  RF  and  modem 
techniques  are  controlled.  Other  applications  for  example  in  memory  control 
functions,  microprocessor  control  can  eliminate  latency  time  and  allow  more  task 
overlays,  minimize  main  memory  usage. 

Of  interest  to  a structured  design  are  alternate  methods  of  software  support  for 
microprocessor  program  generation  and  configuration  control.  Functional  replacements 
which  require  no  software  support  and  which  modify  or  replace  logic  can  be  designed 
solely  by  functional  and  interface  specifications.  This  functional  median  ism  can  also 
include  implementations  of  primitive  functions  for  larger  scale  computing.  General  CP 
utilization  of  microprocessors  requires  support  of  language,  and  language  processors. 
A language  hierarchy  is  shown  in  figure  12.  Most  appropriate  for  efficiency  is  a 
machine  oriented  language,  however  it  compromises  the  portability  to  other  machines  of 
newer  technology.  More  advantageous  is  a problem  oriented  high  level  language  with 
macros  or  subroutines  related  to  system  design  or  functional  design  as  in  the  case  of 
signal  processing  routines  common  to  sensor  signal  filtering,  detection,  tracking, 
etc.  It  is  estimated  that  such  language  would  cover  95%  of  the  real  time  applications 
with  primitive  functions.  A set  of  guideline  specifications  by  which  subroutines  can 
be  written  in  mnemonics  and  later  included  in  a library  under  control  of  a HL  problem, 
oriented  language  would  serve  this  implementation  well.  This  procedure  is  being 
incorporated  in  the  acoustic  processing  routine  for  PROTEUS  using  SPL-1,  and  is 
feasible  to  extend  for  microprocessor  routines  in  real  or  non  real  time  system 
programming . 

System  Structure and  Computer  Networking 

We  are  now  at  a point  in  the  design  process  where  we  have  partitioned  system 
functional  algorithms  into  elemental  program  units  as  would  be  done  in  flow  chart 
form,  compiled  their  interdependencies,  simplified  the  latter  by  iteration  of  the 
decomposition  process,  and  assigned  each  program  element  to  an  appropriate 
implementation  in  hardware  software  or  firmware  in  accord  with  criterion.  The 
structured  data  flow  and  control  requirements  of  the  decomposed  functions  will  allow 
us  to  construct  a processing  network  of  resources,  processors,  memory,  (ROM  RAM),  bus 
and  associated  operating  system.  It  now  remains  to  structure  the  elements  into  an 
executable  design,  and  relate  such  a structure  of  program  elements  to  a networking  of 
processor  resources  and  produce  executive  functions  which  control  and  schedule  their 
execution  within  the  network.  The  network  resources,  processors,  memory,  I/O 
channels,  communications  interfaces  and  programmable  or  ROM  controllers  are  selected 
and  connected  on  the  basis  of  required  speed,  storage,  data  transfer  paths,  task 
allocation,  and  the  design  constraints.  To  consider  networking  resources  without 
these  considerations  and  particularly  the  feasibility  of  executive  design  is  sheer 
folly  and  to  a degree  is  responsible  for  complex  traffic  problems  even  in  the  most 
elementary  control  processing  network.  However,  we  have  not  let  this  fact  discourage 
our  creativity  and  in  figure  13,  reference  (c),  we  see  the  universal  computer  resource 
network.  The  direct  I/O,  memory  transfer  can  be  implemented  with  microprocessor  logic 
control,  and  also  with  memory  to  memory  transfer.  Considering  only  one  processor  and 
memory,  with  processor,  I/O,  and  memory  processor  data  transfer  a central  multiplexed 
uniprocessor  results.  Configuring  multiple  units  with  processor  to  processor  data 
transfer,  and  multi  memory  access  and  multiple  I/O  processor  access  results  in  tandem 
multiprocessing  a parallel  dedicated  or  redundant  processing  capability.  Still 
another  configuration,  the  distributed  network  results  when  processors  have  access  to 
all  memories  and  are  directly  related  to  one  I/O  channel. 

When  considered  for  either  avionic  subsystem  or  system  use  this  configuration 
offers  the  most  flexibility  in  the  partitioning  and  allocation  of  functional  pro-gram 
units  to  software,  firmware  or  new  technology  hardware  since  data  is  passed 
efficiently  to  each  processor  which  can  be  related  via  appropriate  calling  sequences. 
Processors  can  be  general  purpose  (programmable)  or  special  purpose  (ROM  or 
hardware).  This  approach  is  most  efficient  and  finds  modern  use  in  achieving 
efficiencies  for  multisensor  signal  processing  with  simplified  programming.  A final 
federated  configuration  results  when  the  only  transfer  path  is  at  the  I/O  level  and 
processor  and  their  associated  memory  are  independently  programmed  and  operated.  No 
programs  are  shared  or  transferred  between  processors.  In  federation,  redundancy  is 
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only  capable  by  virtue  of  duplication.  Considering  the  utility  in  avionics,  figure  14 
shows  a tandem  configuration  for  networking  within  a dual  radar  subsystem.  In  most 
platforms  where  space  and  weight  are  not  at  a premium  normally  dual  systems  would  be 
built  and  only  share  control  or  console  displays.  Here  parallel  operation  of  normal 
modes  are  designed  with  sequential  operation  of  demand  modes  or  recovery  modes  in 
accord  with  design  constraints,  although  reserve  and  growth  can  be  attained  by 
providing  increased  processor  throughput  and  memory  or  additional  processor 
interconnection.  Special  purpose  hardware  is  not  ruled  out  but  in  this  case  can  imply 
more  complex  executive  control  and  scheduling.  Depending  upon  special  sensor 
interconnect  requirements  hardware  can  become  expensive  in  design,  not  necssarily  in 
production.  It  is  appropriate  for  using  an  AN/AYK-14  device  with  programmed  i/O  and 
multiple  memory  parts,  with  memory  controllers.  Because  of  the  above  it  is  easy  to 
recognize  that  careful  functional  radar  mode  partitioning  is  required  here,  and  would 
generally  be  done  by  its  designer  in  a unique  manner,  using  unique  software  or 
hardware  for  achieving  signal  processing  efficiency  with  reduced  overhead.  The 
flexibility  and  expandability  of  this  network  in  the  design  are  directly  traded  for 
executive  complexity.  Next  consider  a mission  related  sensor  subsystem  composed  of 
acoustics,  MAD,  IR  and  optical  sensors  interproces sed  on  a distributed  subsystem  with 
options  of  sequential  or  parallel  processing  in  accord  with  sequential  mission  modes 
(figure  15).  The  appropriateness  of  the  bus  network  here  cannot  be  over  emphasized 
since  federation,  although  requiring  a less  complex  executive  is  cumbersome  for 

buffering  and  transfer  if  multisensor  data  via  multiple  I/O  ports.  Here  alteration 
and  reconfiguration  is  feasible  because  processing  programs  used  in  multiple  sensors 
can  be  shared  by  multiple  processor  and  partitioning  has  potential  for  drastic 
simplifications.  Kalman  tracking  algorithms  utilizing  both  acoustic  and  optical  or 
MAD  data  can  be  effected  with  little  signal  or  data  transfer.  Data  from  any  sensor  or 
sensors  in  combination  is  readily  available  for  correlation  and  display.  The 

structure  and  the  network  support  extensive  expansion  for  reserve  or  added  modes. 
Considering  the  total  of  subsystems  in  avionics  and  the  characteristics  loading  and 
design  constraints  of  each  one  may  assign  networks  in  the  following  manner. 

Communications  - distributed 

Navigation  - tandem 

Radar  - tandem 

Acoustics,  Magnetics,  Optics  - distributed 

ECM/ESM  - federated 

Stores  - central  redundant,  etc 

The  overall  networking  which  integrates  subsystems  must  for  simplicity  be  termed 
distributed  with  selective  task  allocations,  figure  16.  These  schemes  of  networking 
can  then  be  divided  into  our  original  module  concept  of  core  and  mission  avionics  as 

appropriate  and  this  hybrid  planetary  system  is  what  appears  to  support  avionics 

subsystems  most  economically  with  least  projected  overhead.  Emphasizing  that  detail 
implementation  demands  the  structured  procedure.  This  is  shown  in  chart  form  in 
figure  17.  Partitioning,  simulation  and/or  emulation  must  be  iterated  to  evaluate  and 
finalize  design.  The  overall  performance  of  the  design  would  naturally  be  judged  by 
its  cost  and  performance  trade  and  how  well  it  met  design  criterion  such  as  was 
presented  earlier.  To  name  a few,  measurable  quantities,  mission  reliability,  parts 
count,  adaptability,  data  flow,  executive  complexity  and  overhead,  technology 
independence,  etc. 

Summary 


Reflecting  on  the  proposed  process  we  might  ask  the  following  questions.  Is  this 
a vastly  different  process  for  system  design?  Is  it  realistic  and/or  risky?  Does  it 
represent  an  entirely  new  way  of  specifying  and  procuring  avionics?  One  question  at  a 
time!  I might  contend  that  the  process  is  reproduced  in  one  manner  or  another  in  any 
system  design  however  unstructured  and  that  functional  implementation,  and  cost 
tradeoffs  are  made  non-the-less  or  may  be  to  less  advantage  than  can  be  done  with  a 
formal  structured  approach.  Secondly,  realism  is  today's  motto  in  all  realms,  and  if 
the  technical  capacity  is  not  present  our  most  virtuous  goals  are  not  attainable. 
Each  technology  involved  in  this  process  is  available  to  us  during  the  1975-1985  time 
period.  I believe  it  is  still  the  virtue  and  initial  cost  that  we  debate  to  a fault. 
Third,  it  does  represent  a new  approach  and  its  many  features  among  the  most  dominant 
is  the  fact  that  independent  thinking  designers  are  forced  at  the  onset  to  admit 
dependence  to  a benefit  and  not  a hindering,  and  it  is  in  the  interdependence  of  the 
integrated  design  itself  that  value  is  gained  in  adapting  standards  and  a common 
structured  procedure  in  engineering  each  subsystem  although  possibly  contracted  and 
negotiated  separately.  This  design  projection  and  process  may  appear  to  prevent 
competition  in  procurement  or  limit  design  options.  Figure  18,  I hope,  will  show  that 
in  reality  it  is  challenging  design  creativity  to  define  standard  economically 
imp  1 eraen t a b 1 e structures  of  functions  and  merely  preventing  definition  of  such 
challenged  response  as  competitive  edge. 

Observations  which  we  think  can  be  made  from  the  above  discussion  include  the 
following: 

Li 
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. One  of  the  most  realistic  techniques  for  simplification  and  reduction  of 
software  generation  and  maintenance  costs  as  well  as  system  implementation  and 
integration  costs  beyond  the  use  of  common  software  support  and  language  is  the 
partitioning  of  system  and  subsystem  functions  so  as  to  structure  algorithm  elements 
assignable  to  the  most  economic  and  appropriate  implementation  commensurate  with  media 
advantages  and  mission  aircraft  design  constraints. 

. Problem  oriented  languages  and  macros  primitive  to  system  algorithm  functions 
go  a long  way  in  assuring  program  reproduction,  transportability  and  expansion  cost 
reduction,  particularly  in  microprocessor  design  and  programming. 

. A method  of  processor  and  peripheral  device  networking  does  not  of  itself 
constitute  architectural  completeness,  but  must  be  done  in  consort  with  structured 
partitioning,  device  modularity  and  A/C  design  constraints  and  must  be  such  as  to 
allow  feasibility  of  executive  functions  without  overburdening  complexity. 

. Avionic  systems,  by  virtue  of  a variety  of  missions  and  peculiar  functional 
approaches  to  core  and  mission  subsystem  design  constraints  are  best  supported  by  a 
planetary  network  of  hybrid  structures,  and  subsystem  networks  unified  by  multipurpose 
connective  buses  at  subsystem  and  system  levels. 


. Structured  partitioning  techniques,  interdependence  definition,  and  composition 
of  algorithmic  functions  into  realistic  imp  1 emen t ab 1 c elements  offers  the  strongest 
and  most  realistic  approach  to  uniting  the  advantages  of  LSI  technology,  language 
interfaces,  and  distributed  resource  techniques  to  accomplishing  economical  next 
generation  avionics  systems. 
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FIGURE  1 - EVOLUTION  OF  AVIONICS  PROCESSING 
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FIGURE  2 - SYSTEM  APPLICATIONS 
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FICURE  2 A - COST  EFFECTIVE  SYSTEM  IMPLEMENTATION 
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FIGURE  5 - MATRIX  OF  AVIONIC  SYSTEMS/FUNCTIONS 
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DISCUSSION 


J.N. Bloom 

Considering  the  complexity  of  the  problem,  what  are  the  requirements  on  management  to  administer  such  a 
structured  process? 

Author’s  Reply 

Assuming  the  structured  process  referred  to  is  that  of  avionics  design  with  a unified  data  handling  scheme,  the 
management  requirements  are  as  follows: 

Direct  and  detailed  technical  management  of  data  handling  interface. 

Delegation  by  platform  management  of  standards  for  interfaces  (1 553B),  languages,  software  control, 
hardware  functions. 

Configuration  management  of  functional  software  modules,  hardware  functional  chips,  executive  control 
interfaces,  diagnostic  and  BITE  procedures. 

Delineation  of  standards  in  subcontracts,  and  definition  of  GFE  software,  hardware  selections. 

Contract  review  and  redirection  to  maintain  unified  objectives. 

Personnel  staffing  with  skills  required  for  standards  definition  and  design. 


J.N. Bloom 

What  reporting  procedures  do  you  advocate  and  what  reporting  interval  do  you  propose  in  order  to  avoid  chaos? 

Author’s  Reply 

1 would  recommend  a prime  project  staff  located  within  150  ft  of  each  other  with  responsibility  for  each  major 
subsystem  and  semi-monthly  reviews  of  design,  contracting,  configuration,  test,  data,  and  plans  for  expenditures. 
Reporting  should  be  to  one  individual  (staff)  for  standards  and  configuration  control  of  software,  hardware, 
firmware  modules,  and  language  interfaces.  Additional  groups  can  be  staffed  to  review  performance  and 
maintainability,  test,  etc. 
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Tactical  Automated  Message  Processing  Systems 


Ruth  Nelson  and  Joseph  Jarzembowski 
GTE  Sylvania  Incorporated 
Communication  Systems  Division 
189  "B”  Street 
Needham  Heights,  MA  02194 

Summary 

The  automation  of  text  message  handling  is  a recognized  requirement  for  both  strategic  and  tactical 
command  centers.  Because  tactical  centers  do  not  have  as  extensive  data  processing  capabilities  as 
those  available  at  strategic  centers,  it  has  been  suggested  that  tactical  users,  particularly  mobile  ones, 
should  draw  on  the  resources  of  large,  fixed  centers  for  some  of  the  services  requiring  large  amounts  of 
computer  power.  This  paper  discusses  some  possible  approaches  to  providing  tactical  message  handling 
services  and  their  effects  on  the  design  of  both  the  tactical  and  strategic  systems.  GTE  Sylvania’s 
Communication  Systems  Division  has  analyzed  the  message  handling  requirements  for  both  large 
WWMCCS  command  centers  and  small  battlefield  centers  and  has  evaluated  the  implementation 
constraints  of  tactical  systems  and  differences  in  emphasis  for  the  various  systems.  If  automated 
message  handling  is  to  meet  its  goal  of  improved  writer-to-reader  communications,  it  is  imperative  that 
both  strategic  and  tactical  systems  designers  consider  the  issues  of  allocation  of  functions  and  of 
tactical/strategic  interoperability. 

1.0  Introduction 

Systems  for  providing  Automated  Message  Processing  (AMPS)  are  currently  being  designed  and 
implemented  for  large,  fixed  military  command  centers.  There  is  a clear  requirement  to  provide  this 
automation  to  deployable  tactical  centers  as  well.  Since  these  tactical  centers  will  interoperate  with  the 
fixed  AMP  facilities,  it  is  time  to  consider  the  automation  of  message  processing  in  the  tactical 
environment.  As  will  be  seen,  the  capability  for  interoperability  cannot  simply  be  added  to  an  existing 
message  processing  system  but  must  be  well  integrated  from  the  earliest  stages  of  design. 

The  primary  purpose  of  any  AMPS  is  to  speed  writer-to-reader  transit  of  narrative  messages 
between  command  centers.  The  AMPS  must  provide  assistance  in  message  composition  and  coordina- 
tion at  the  source.  At  the  destination,  messages  must  be  routed  by  address  and  by  subject,  and 
disseminated  to  appropriate  personnel.  However,  AMPS  also  functions  as  part  of  a “decision  support 
system”  for  crisis  management.  Working  files  of  messages  can  be  maintained  by  subject,  and  the  system 
should  allow  rapid  retrieval,  examination,  and  annotating  of  these  messages  at  display  screen  consoles. 

The  WWMCCS  architecture  and  related  studies  have  described  the  extensive  functions  of  AMPS  as 
required  at  large  fixed  WWMCCS  command  centers.  At  deployable  tactical  centers,  however,  some  of 
these  functions  can  be  done  manually,  some  need  not  be  done  at  all,  and  the  number  of  messages  per  day 
may  be  lower.  This  leads  to  a reduced  set  of  overall  message  processing  requirements  for  the  tactical 
system.  Some  of  these  requirements  may  be  met  by  the  tactical  AMPS  as  a standalone  system,  and  some 
may  be  provided  for  the  tactical  users  by  a remote,  fixed  site  system.  Whatever  the  mix  of  services 
provided  by  the  fixed  site  for  tactical  users  or  services  provided  at  the  tactical  center,  it  is  clear  that 
requirements  such  as  message  storage  and  fast  response  time  for  narrative  messages  imply  tactical 
message  processing  capability.  This  paper  will  discuss  some  alternate  approaches  to  this  distributed 
processing  problem.  Factors  to  be  considered  include  the  tactical  system  hardware  architecture,  the 
constraints  on  the  fixed  site  AMPS  design,  especially  in  the  area  of  security,  and  the  issues  of  system 
performance  and  interoperability. 

2.0  Definition  of  Automated  Message  Processing  Systems 

Effective  operation  of  command  centers  — both  strategic  and  tactical  — depends  in  part  on  the  efficient 
performance  of  a variety  of  clerical  details.  Many  of  these  are  associated  with  distribution,  review, 
coordination  and  preparation  of  narrative  text  message  traffic.  Most  major  centers  have  some  degree  of 
message  center  automation,  usually  relating  to  message  distribution  and  storage;  but  message  receipt 
and  origination  at  the  desk/action  officer  level  remain  essentially  a manual  process.  A lack  of  auto,  lation 
at  this  level  can  cause  delays  in  message  handling  to  increase  drastically  with  the  extra  message  volume 
during  crisis  situations  or  other  periods  of  intense  activity.  The  effort  required  to  handle  this  crisis  traffic 
may  cause  cognizant  personnel  to  be  overloaded.  This  overload  situation  can  result  in  misplaced 
priorities,  diverted  action  items  and  unanswered  or  misdirected  messages,  to  itemize  only  a few 
difficulties. 


1 


Automated  Message  Processing  Systems  are  designed  to  extend  the  automation  now  provided  by 
communications  centers  and  message  networks  to  the  command  centers  and  so  to  alleviate  the  overload 
situation  as  well  as  to  provide  an  increase  in  message  center  efficiency  during  normal  operation. 

The  mqjor  capabilities  to  be  provided  by  an  automated  message  processing  system  are  as  follows: 

• Support  the  receipt,  indexing,  storage,  and  distribution  of  incoming  text/narrative  me  sages. 

• Provide  on-line  capabilities  to  retrieve,  review  and  manipulate  stored  text  messages. 

• Support  the  preparation  and  transmission  of  operation  orders,  outgoing  directives,  and  other 
text  messages,  as  required. 

• Provide  direct  terminal  support  to  desk  officers,  action  officers,  and  other  internal  command 
center  staff  members  for  activities  associated  with  text  message  handling. 

These  major  capabilities  are  required  for  an  AMPS  at  any  command  center,  whether  strategic  or 
tactical,  fixed  or  deployable.  However,  the  specific  requirements  for  a particular  system  will  vary 
depending  on  mission  characteristics,  the  amount  of  message  traffic,  types  of  message  sources  and 
destinations,  the  sophistication  of  the  decision  support  provided,  the  degree  of  interoperability  with 
other  systems  and  the  level  of  communications  support  required.  These  requirements  must  be  evaluated 
on  a site  by  site  (or  mission)  basis. 

In  general,  however,  because  of  the  above  considerations,  the  functional  requirements  for  a tactical 
AMPS  will  be  a subset  of  WWMCCS  fixed  site  requirements.  The  WWMCCS  approach  to  AMPS  will 
therefore  be  examined  first.  It  should  be  noted,  in  addition,  that  significant  portions  of  the  design  and 
some  lesser  amount  of  the  software  for  Automated  Message  Processing  Systems  at  tactical  command 
centers  can  likely  be  derived  from  the  WWMCCS  fixed  site  approach.  Additionally,  the  WWMCCS 
Transition  Plan  follows  this  observation  by  suggesting  that  the  deployable  AMPS  act  as  a remote 
terminal  of  the  fixed  site  and  use  the  larger  system  for  additional  processing  and  message  storage. 


2. 1 WWMCCS  Message  Processing  System  — Operational  Concept 

The  WWMCCS  Transition  Plan  includes  an  operational  concept  for  Automatic  Message  Processing 
Systems  at  WWMCCS  Command  Centers.  Messages  reach  the  Command  Center  via  an  assortment  of 
communication  systems.  Once  a message  has  arrived,  the  AMPS  will  write  a journal  entry  on  a message 
log,  assign  message  identification  codes,  store  the  message  for  on-line  recall,  and  automatically  distri- 
bute each  message  to  the  appropriate  recipient.  A Master  Message  Terminal  operator  oversees  and 
coordinates  distribution  and  acts  as  a default  message  queue  for  all  messages  which  do  not  match  any 
user-interest  text  profile.  Special  handling  is  provided  for  high  precedence  and  other  designated  message 
types. 

Messages  are  queued  by  precedence  and  date-time-group  at  each  CRT  terminal,  and  users  will  be 
notified  of  theii  arrival.  The  users  can  view  the  message  on  request,  and  can  override  the  AMPS 
generated  queue  to  view  messages  in  any  desired  order.  In  addition,  the  system  will  permit  the  user  (in 
this  case  a message  recipient)  to: 

a.  F.dit  and  annotate  the  messages; 

b.  Store  the  original  (or  modified)  message  in  either  a data  base  file  (e.g.,  crisis  file)  or  in  a private 
user  file; 

c.  Route  the  original  (or  modified)  message  to  other  terminals; 

d.  Initiate  a conference  with  other  terminals  on  the  contents  of  the  message; 

e.  Hold  the  message  in  his  queue  pending  further  action,  and 

f.  Purge  the  message  from  his  queue. 

The  user  can  recall  messages  by  date-time-group,  originator  reference  code,  subject,  disseminee. 
etc.  Once  he  has  retrieved  a message,  he  can  perform  any  of  the  above  operations  on  it. 

When  the  AMPS  user  is  using  the  system  to  facilitate  message  composition,  release  and  transmis- 
sion. the  AMPS  provides  a file  of  preformatted  message  forms  and  messages,  and  it  will  assist  the 
operator  in  message  header  assembly  and  in  assignment  of  addressees,  precedence,  and  security  codes. 
"Cut-and-paste"  editing  capabilities  will  allow  recalled  references  and  messages,  or  parts  of  these,  to  be 
incorporated  in  a new  message  as  it  is  being  composed. 


Draft  messages  can  be  stored  and  routed  to  other  terminals  for  coordination,  authorization,  and 
release.  After  completion  of  this  process,  the  system  will  transmit  the  message  to  the  telecommunica- 
tions center  for  output,  and  receive  a positive  indication  from  the  message  center  of  message  receipt. 


In  addition  to  the  operational  capabilities,  the  AMPS  will  also  provide  for  informal  interuser  memos, 
user  conferences,  on-line  modification  of  user  profiles,  and  training  and  exercise  support. 

Table  I summarizes  the  major  AMPS  functional  requirements  for  fixed  WWMCCS-like  command 
centers.  The  table  clearly  shows  the  distinction  between  a message  processing  system  and  a message 
switch  or  communications  center.  The  WWMCCS  AMPS  complements  an  automated  telecommunica- 
tions capability,  but  does  not  provide  it. 


Table  I 

AMP  Major  Functions  and  Derivative  Capability  Objectives  (Ref.  1) 


• Telecommunications  Center 
Interface 

— Acknowledge  notification 
— Journal,  log 
— Precedence/DTG  Queuing 
— Misroute  intercept 

• Message  Distribution 

— Automated  distribution 
based  on  message  profile 
(e.g.,  subject,  “for”  indi- 
cator, references) 

— Dissemination  review  at 
master  message  terminal 
for  semiautomatic,  "ad 
hoc”  routing 

— Addressee-arranged  pre- 
cedence queues 
— Incoming  message  notices 
(e.g.,  audio/visual  alarms) 

• Message  Storage 

— Storage  of  original/ 
modified  copy 

— Subject  index  insertion  for 
correlation  recall 
— Move  messages  from/ 
among  files 


• Message  Retrieval 

— Message/data  menus 
— Recall  by  specified  subject 
— System  notices  (e.g., 
retrieval/query  errors, 
additional  information 
required  to  process 
query) 

• Message  Composition/ 
Transmission 

— Fill-in-the-blanks  forms 
— Assembly  of  message 
headers 

— Semi-automated  addres- 
see, precedence,  security 
assignment 

— Text  edit  capabilities 
— Handoff  for  coordination, 
authentication,  release 
— Come-back  copy  posting 

• Security 

— Prevent  unauthorized  dis- 
closure 

— Prevent  unauthorized 
transmission 

— Security/privacy  indicators 
— Authorization  control 


• User-Oriented  Features 
— Shift  log 

— Crisis  log 

— Action/information  message 
log 

— Private  working  files 
— Historical  files 
— Reference  files 
— Pending  action  queue 
— Hold  queue 
— Console-to-console 
communications 
— Multi-terminal  conferencing 
— System  notices 
— Automated  assistance 
— Dynamic  message  profile 
modification 

• Exercise  Support 

— Parallel  real-exercise  modes 
(by  terminal) 

— Simulated  incoming  message 
and  prestored  data  genera- 
tion 

• Statistics  Gathering 

— In/out  traffic  volume 
— “In-house”  transaction 
elapsed  time 

— Query  /response  elapsed  time 
— System  failures/down  time 


2.2  WWMCCS  AMPS  Processing  Requirements 

As  part  of  a technical  analysis  and  cost  estimate  (TA/CE)  for  implementing  automated  text  message 
handling  at  the  Pacific  Fleet  Command  Center  in  Hawaii,  GTE  Sylvania  estimated  the  amount  of  A DP 
support  required  for  a standalone  automated  message  processing  system.  Standalone,  in  this  context, 
means  that  no  other  existing  ADP  facilities  were  adapted  for  use  in  the  AMP.  The  TA/CE  concentrated 
on  a standalone  system  because  of  the  severe  disruption  to  existing  system  capabilities  if  they  were 
modified  to  support  distributed  AMP.  It  should  be  noted  that  that  study’s  results  are  very  site  dependent 
as  regards  possible  implementation.  Because  the  Pacific  FCC  AMPS  is  a standalone  design,  however, 
much  can  be  gleaned  from  it  concerning  WWMCCS  AMPS  processing  requirements. 

Our  TA/CE  estimates  assumed  that  telecommunications  support  would  be  provided  by  an  LDMX 
installation,  that  there  would  be  16  AMPS  user  terminals,  and  that  the  crisis  message  load  would 
approximate  2400  messages  per  day.  The  WWMCCS  AMPS  concept  requires  5-day  message  storage  or 
about  800  x 10“  bits.  The  response  time  requirements  are  shown  in  Table  2. 

With  these  requirements  we  calculated  that  two  Digital  Equipment  Corporation  PDP-1 1 /70s  could 
provide  the  required  processing  power.  The  reliability  of  such  a configuration  is  much  less  than  the  .9995 
recommended  by  the  WWMCCS  Transition  Plan  since  the  processors  are  not  redundant.  GTE  Syl- 
vania's  recommended  configuration  includes  the  two  processors,  each  with  218.000  words  of  memory, 
three  dual  access  disks  (one  controller)  with  a u»tal  of  132  million  words  of  on-line  storage,  three 
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nine-track  magnetic  tape  units,  line  printer,  card  readers,  and  intelligent  high  speed  C R I terminals.  Even 
with  this  large  computer  installation,  there  is  not  sufficient  capacity  for  redundant  message  storage  nor  is 
there  a back-up  processor  for  added  reliability. 


We  did  not  include  a redundant  processor  because  of  cost  considerations  and  because  of  the  large 
amount  of  message  related  A DP  equipment  on  site.  Some  back-up  processing  could  be  provided  by  this 
other  equipment  in  an  emergency  although  not  with  all  of  the  AMPS  functions  or  coherence.  Thus,  our 
estimates  agree  very  closely  with  the  WWMCCS  prediction  that  a four  processor  system  would  be 
required  for  reliable  automatic  message  processing  at  a WWMCCS  fixed  site. 

Table  2 

WWMCCS  AMPS  Response  Time  Requirements 

Performance 


Capability  (In  Seconds) 

a.  Input  message  receipt  to  desk/action  officer  notification  60 

b.  Retrieve  and  display  a user  selected  message  2 

c.  Delivery  of  FLASH  or  higher  message  to  desk/action  officer  10 

d.  Retrieve  and  display  a previously  stored  display  from  data  base  3 

e.  Acknowledge  a user  kevboard  action  2 

f.  Route  a display/message  from  one  user  terminal  to  another  5 

g.  Transmit  an  outgoing  message  00 

h.  Produce  hardcopy  output  from  a single  screen  15 


3.0  Tactical  Message  Processing 

This  section  will  discuss  the  major  requirements  for  an  automated  message  processing  system  in  a 
tactical  environment.  Possible  allocations  of  these  requirements  among  tactical  and  fixed  site  systems 
will  be  discussed  in  terms  of  distribution  of  functions  and  interoperability. 

3.1  Tactical  Message  Processing  Functional  Requirements 

Because  of  operational  differences,  arising  out  of  mission  characteristics,  between  a large  WWMCCS- 
type  command  center  and  a deployable  tactical  installation  and  the  fact  that  the  tactical  center  can  rely 
on  the  fixed  center  to  some  extent,  a smaller  ADP  implementation  can  probably  meet  all  of  the  tactical 
message  piocessing  requirements. 

The  major  impact  on  the  WWMCCS  AMPS  comes  from  the  number  of  messages  processed  per  day . 
the  number  of  terminals  which  must  be  supported,  and  the  elaborate  message  profiles  needed  for 
efficient  management  of  complex  situations.  The  tactical  AMPS  is  a smaller  and  less  complex  system. 
Table  3 shows  a comparison  of  strategic  and  tactical  system  design  goals. 


Table  3 

Comparison  of  Strategic  and  Tactical  System  Design  Goals 


— 

WWMCCS  Center 

Tactical  Center 

• 1 raffle  load 

2400  msgs/day  — crisis 

500-2400  msgs/day  — crisis 

• Terminals  supported 

12-16 

3-4 

• Messages  stored 

5 days 

24  hours 

• Message  distribution  by 

key  words 

subject  line 

user  profile 

message  type 

• Communications 

many 

fewer 

interfaces/formats 

• Exercise  support  capability 

required 

optional 

• Handoff  for  coordination 

required 

informal 

• Message  generation  support 

canned  formats,  editing 

canned  formats,  editing 

• Security 

multilevel,  intelligence 

multilevel  or  system  high 

3.2  Tactical  Message  Processing  System  Operation 

From  Table  3 it  can  be  seen  that  the  message  processing  requirements  at  a tactical  command  center  are 
substantially  less  than  those  required  at  a large  WWMCCS  center.  The  current  state  of  the  art  allows  the 
tactical  AMP  to  operate  in  either  a standalone  mode  or  in  a distributed  processing  configuration. 


In  a distributed  processing  configuration  the  tactical  AMPS  would  rely  on  a WWMCCS  fixed  site  for 
support  in  message  storage,  message  distribution,  exercise  support  and  communications  interfaces. 
Note  that  it  is  likely  that  tactical  AMPS  will  have  sufficiently  narrow  missions  to  preclude  a universal 
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implementation.  This,  in  turn,  implies  the  design  of  a WWMCCS  command  center  which  may  have  to 
support  several  different  tactical  AMPS.  The  WWMCCS  Transition  Plan  assumes  that  deployable 
AMPS  will  operate  as  a distributed  system,  in  some  cases  as  remote  terminals.  We  will  explore  some 
further  implications  of  this  approach  in  Section  3.5. 

The  recent  availability  of  large  minicomputers  for  military  use,  notably  the  Norden  version  of  the 
DEC  PDP  1 1/70  may  lessen  the  tactical/strategic  interoperability  problem  by  providing  the  means  for  a 
standalone  version  of  a tactical  AMPS. 

3.3  Independent  Tactical  Message  Processing  System 

With  the  reduced  tactical  AMP  requirements,  it  is  clearly  possible  to  design  a totally  standalone  AMPS 
for  tactical  use.  This  independent  system  would  maintain  its  own  message  data  bases,  perform  all  of  its 
own  processing  and  format  messages  as  required  for  any  interfacing  network,  etc.  The  interface  to  other 
command  centers  would  be  through  the  communications  center  by  means  of  narrative  messages  or  an 
AUTODIN  Query/Response  type  capability.  Because  there  is  no  interface  with  other  AMPS  except  via 
messages  and  because  these  messages  are  directed  from  one  person  to  another  and  are  not  automatically 
processed,  this  standalone  AMPS  has  minimal  interoperability  requirements.  In  fact,  the  only  require- 
ments are  interoperability  of  the  communications  systems  and  compatible  message  formats.  If  simplicity 
of  implementation  and  straightforward  achievement  of  interoperability  are  the  primary  design  require- 
ments, then  a standalone  system  is  clearly  the  best  choice. 

An  independent  tactical  AMPS  has  major  additional  advantages  if  the  WWMCCS  fixed  site  version 
adopts  the  DEC  PDP- 1 1/70  processor  (as  seems  likely).  A tactical  system  could  then  use  the  NORDEN 
PDP-I I/70M  militarized  version,  which  is  entirely  software  compatible.  The  use  of  fixed-site  software 
would  probably  greatly  reduce  the  development  cost  and  schedule  of  tactical  AMP  and  allow  earlier 
extension  of  this  capability  to  the  tactical  world. 

3.4  Arguments  for  Distributed  System 

The  major  arguments  against  a fully  capable,  independent  AMPS  are,  of  course,  the  resources  required, 
especially  those  of  space  and  power.  Message  processing  is  not  the  only,  nor  in  fact  the  major  function  of 
a tactical  command  center,  and  the  allocation  of  two  large  midicomputers  with  full  complements  of 
peripheral  equipment  is  one  which  would  require  substantial  justification.  While  a standalone  system 
may  be  optimal  from  an  implementation  and  performance  viewpoint,  it  is  probably  not  the  best  choice  for 
any  but  the  largest  tactical  sites. 

A further  argument  against  using  the  available  ADP  resources  for  standalone  AMPS  lies  in  the  need 
for  integrating  command  center  C3  operations.  At  the  WWMCCS  command  centers,  there  are  separate 
ADP  systems  provided  for  Communications  (LDMX,  AMME.  etc.),  General  data  processing 
(WWMCCS  ADP),  intelligence  data  processing,  and  Automated  Message  Processing.  Generally,  each 
of  these  systems  has  separate  staffing,  terminals,  etc.  and  they  all  have  separate  processor  configura- 
tions. The  systems  communicate  with  each  other  via  data  links  of  various  speeds,  but  in  distributed 
processing  terms,  the  command  center  is  a very  loosely  coupled  system.  Efforts  are  currently  underway 
to  integrate  some  of  the  command  center  functions  to  provide  the  staff  with  a more  complete  view  of  the 
situation.  However,  restrictions  on  data  access  require  a solution  to  the  multilevel  security  problem 
before  more  than  token  integration  is  possible. 

In  a tactical  center,  the  smaller  staff,  more  unified  mission,  anu  space  and  power  constraints  all 
increase  the  need  for  an  integrated  C3  system.  In  fact,  if  automating  the  message  handling  and  communi- 
ations  functions  results  in  an  increase  in  the  amount  of  information  which  must  be  acted  on  by  staff 
personnel,  this  will  also  result  in  an  increase  of  the  effort  required  for  analysis  and  evaluation  of  the 
communicated  information  at  the  tactical  center.  If  some  of  the  less  mission-critical  information  and 
message  processing  can  be  offloaded  from  the  tactical  command  center  to  a remote  fixed  site,  then  more 
ADP  resources  can  be  directed  towards  the  needed  data  analysis  and  the  tactical  system  can  provide  real 
decision  and  management  support  to  the  battle  itself. 

3.5  Distributed  Processing  Impacts 

A distributed  AMPS  concept  envisions  the  tactical  AMPS  as  a sophisticated  remote  terminal  to  a fixed 
system,  with  the  tactical  AMPS  strongly  committed  to  decision  and  management  support.  This  concept 
implies  that  each  tactical  AMPS  would  rely  on  the  fixed  site  for  a large  part  of  the  more  “mundane" 
AMPS  processing  such  as  message  distribution,  message  storage  and  retrieval.  As  previously  noted,  it  is 
likely  that  tactical  AMPS  will  have  sufficiently  narrow  missions  that  will  preclude  universal  implemen- 
tation. 
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There  is  a strong  implication  in  this  observation  that  the  design  of  a WWMCCS  command  center 
must  support  several  tactical  AMPS  in  adynamic  manner.  In  addition,  our  research  for  the  Pacific  FCC 
showed  that  distributing  a message  processing  system  among  loosely  coupled  processors  increases 
system  response  time  by  a factor  ranging  from  two  to  three  depending  on  configuration.  One  could 
expect,  then,  not  only  the  tactical  AMPS  response  to  be  lessened  but  also  to  expect  the  fixed  site 
processing  to  degrade,  especially  if  more  than  one  tactical  AMPS  draws  on  it  for  support. 

To  date,  there  is  little  evidence  that  the  interoperability  problems  arising  from  the  concept  of 
distributed  message  processing  have  been  given  the  attention  or  emphasis  they  deserve.  There  are  at 
least  three  major  interoperability  considerations  that  must  be  addressed: 

First,  there  is  a security  problem  introduced  by  the  fact  that  the  security  level  of  the  deployable 
command  center  is  unlikely  to  be  the  same  as  that  of  the  fixed  center  acting  as  host  site.  Note  that  if  the 
entire  deployable  system  is  at  a single  security  level,  then  it  does  not  require  multilevel  security;  it  is  the 
responsibility  of  the  host  site  to  provide  the  security  protection  in  this  case.  This  separation  of  levels  may 
pose  a major  problem  for  fixed-site  AMP  and  may  require  either  full  multilevel  security,  a filtering 
interface  processor,  or  some  other  security  mechanism. 

A second  interoperability/security  problem  is  introduced  if  the  deployable  “remote  terminals" 
access  fixed  AMPS  facilities  via  the  AUTODIN  communications  network.  Fixed  site  AMP  terminals  are 
presumably  on-site  and  hardwired  so  that  only  nominal  terminal  authentication  procedures  are  neces- 
sary For  remote  access  via  DSCS  satellite,  or  other  means  through  the  network,  it  is  clearly  necessary  to 
completely  authenticate  any  connection  and  all  requests  for  access  to  the  data  base. 

The  last  interoperability  consideration  addressed  here  is  the  insurance  of  increased  writer-to-reader 
speed  of  service,  which  is,  after  all,  the  major  goal  of  automated  message  processing.  As  our  analysis  has 
shown,  distributing  functions  between  deployable  and  fixed  sites  introduces  significant  increases  in 
response  times.  Candidate  existing  systems  and  adaptations  thereof  must  be  carefully  analyzed  and 
designed  to  insure  that  the  speed  advantages  provided  by  automation  are  not  outweighed  by  the  delays 
caused  by  the  need  for  multiple  exchanges  between  the  host  and  deployable  systems  Both  the  message 
handling  procedures  and  the  speed-of-service  provided  by  the  communications  network  enter  into  this 
performance  analysis. 

It  must  -riously  be  questioned,  then,  whether  a distributed  AMPS  can  be  justified  in  terms  of  either 
performance  of  capability. 

Conclusion 

The  degree  to  which  automated  message  processing  can  be  provided  for  deployable  tactical  centers 
depends  on  the  level  of  capability  to  be  provided  and  a resolution  of  the  interoperability/security 
problems  between  fixed  WWMCCS  command  centers  and  deployable  tactical  centers. 

Although  a distributed  tactical  AMPS  capability  is  desirable  from  several  viewpoints,  an  im- 
plementation of  this  concept  must  be  reserved  for  the  long  term  pending  an  assessment  and  resolution  of 
the  interoperability  and  security  issues  discussed  in  this  paper. 

For  the  near  term,  deployable  tactical  centers  must  rely  on  standalone  systems  for  automated 
message  processing.  While  the  NORDEN-1 1/70M  can  provide  full  tactical  AMP  capability  if  necessary, 
it  is  by  no  means  clear  that  a full  capability  is  always  necessary  or  desirable.  For  these  situations  a subset 
of  the  full  tactical  AMP  capability  must  be  developed. 
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DISCUSSION 


A.Clearwaters 

You  indicated  that  one  of  the  major  problems  with  a distributed  system  is  that,  in  times  of  stress,  system  services 
will  change  to  loading.  Since  dedicated  systems  must  also  exchange  messages  and  it  is  clear  that  the  message  traffic 
will  increase  dramatically  during  stressful  times,  won’t  dedicated  systems  experience  the  same  kind  of  problems 
you  ascribe  to  a dedicated  approach? 

Author’s  Reply 

It  is  true  that  the  message  traffic  will  increase  in  a crisis,  and  this  is  independent  of  the  system  design.  However, 
because  of  traffic  load  or  a breakdown  in  the  specific  communications  path  between  a tactical  AMP  and  its  host 
system,  the  actual  functionality  of  the  system  may  change  (degrade)  during  a crisis.  This  qualitative  change  and 
elimination  of  some  system  capability  presents,  I think,  a far  more  serious  operational  problem  than  just  the 
extended  reponse  times  caused  by  heavy  message  traffic. 


l.Mirman 

As  I understand  it,  key  words  are  used  to  index  messages  for  retrieval.  Do  you  think  it  possible  to  classify  messages 
in  terms  of  importance,  change,  redundance,  surprise,  etc.? 

Author’s  Reply 

The  key  word  retrieval  capability  now  attainable  can  certainly  be  used  to  classify  messages  for  such  things  as 
relevance  to  a situation,  timeliness,  explicitly  stated  precedence,  addressee’s  name,  etc.  The  intent  of  the  AMP 
system  is  to  allow  the  command  center  staff  to  select  a profile  of  interest  parameters  and  to  change  this  profile  as 
the  situation  evolves.  If  the  parameters  of  change,  redundancy  and  surprise  could  be  precisely  described  in  terms 
of  message  content  or  header  information,  these  parameters  could  be  used  as  well.  However  the  exact  description 
of  these  is,  I believe,  beyond  the  capability  of  current  system  users  and  designers. 
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I - INTRODUCTION 


Le  terminal  faisant  l'objet  de  cette  communication  s'integre  dans  le  systeme  ATILA  (Automat isation  des 
Tirs  et  des  liaisons  de  1 ' Art i 1 ler ie) . II  a ete  developpe  sous  la  responsabilite  de  la  DTAT/Sec tior.  d'Etudes 
et  de  Fabrications  des  Telecommunications  (DTAT/SEFT) . Sur  le  plan  des  objectifs,  le  terminal  participe  aux 
quatre  concepts  : 


I.l  - Aide  a 1 ' automatisation  du  feu 


Le  terminal  possede  un  ou  plusieurs  postes  de  dialogue  (Ecran  + Clavier  alphanumer ique) . L'operateur, 
charge  des  tirs,  travaille  sur  des  grilles  (Figure  1)  dont  le  format  a ete  etudie  pour  miniraiser  les 
erreurs  humaines,  reduire  le  temps  de  formation  et  accroltre  la  rapidite  des  prises  de  decisions. 

Le  terminal  retransmet  automat iquement  les  parametres  de  tir  destines  aux  pieces  d'artillerie  (a  chaque 
piece,  un  systeme  de  teleaf f ichage  a haute  securite  de  visualisation  permet  d’afficher  ces  parametres). 


1.2  - Reseau  de  transmissions  de  donnees 


Les  differents  interesses  (officiers  du  commandement , officiers  de  tir)  du  champ  de  bataille  echangent 
leurs  informations  par  1 ' intermediate  des  postes  de  dialogue  et  sont  abonnes  a un  reseau  de  tnnsmissions 
radio  hierarchise.  Le  terminal  realise  chacun  des  centres  nodaux  du  reseau  et  assure  : 


une  transmission  automatique  des  messages, 

une  affectation  rapide  de  1 ' inf ormation  entre  les  divers  abonnes, 

une  securite  dans  1 ' acheminement  de  1 ' inf ormation, 

une  amelioration  des  temps  de  reponse  de  la  chatne  d'artillerie, 

un  acheminement  adaptatif  du  message  en  cas  de  perturbations  locales  du  reseau  (ou  retour  a l'origine) 


1.3  - Aide  au  commandement 


Le  commandement,  abonne  au  reseau,  en  est  l'animateur  principal.  II  dispose  pour  cela  d'un  calculateur 
qui  met  a sa  disposition  1 'ensemble  des  informations  necessaires  au  suivi  de  1 'evolution  du  champ  de 
bataille  (Base  de  donnees).  Dans  ce  cas,  le  terminal  joue  le  role  d'un  terminal  lourd  de  visualisation  et 
assure  la  collecte  et  1 ' acheminement  de  toutes  les  informations  necessaires  a la  chaine  d'artillerie. 


1.4  - Adaptations  a differents  besoins 


Le  terminal  est  programmable.  Sa  structure  lui  permet  done  de  s'adapter  selon  les  besoins  a des  systemes 
en  mode  reseau  centralise  ou  decentralise  (Figures  2a  et  2b).  Le  passage  d'un  systeme  a un  autre  est  semi- 
dynamique  (inferieur  a une  heure) . La  structure  du  systeme  ATILA  centralise  est  donnee  figure  2c. 


2 - STRUCTURE  SYSTEME  DU  TERMINAL 


Sur  le  plan  de  la  structure  systeme,  le  terminal  peut  etre  considere  comme  une  machine  "Interface 
operateur"  (M  : I)  associee  a une  machine  de  commutation  (M  : C) . Globalement,  la  structure  se  presente 
sous  la  forme  "Image"  suivante  : 


Interface  du  type  "Echange  de  contexte1 


I: 

I 

B 


f 

I. 


■ 
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2.1  - Description  de  la  machine  M:I 

Cette  machine  permet  le  dialogue  de  l'operateur  avec  1 ' environnement  externe.  Dans  le  cadre  du  terminal, 
les  moyens  de  dialogue  de  l'operateur  sont  des  ecrans  de  visualisation  et  des  claviers.  La  relation  avec  le 
"puits  de  donnees"  se  fait  par  1 ’ intermediate  : 

- d'une  liaison  parallele  asynchrone  (Machine  M : SX)  pour  le  terminal  relie  au  calculateur 
(variante  correspondant  au  commandement) , 

- d’une  liaison  bande  magnetique  (Machine  M : SY)  pour  le  terminal  autonome 
(variante  correspondant  aux  batterie  et  detachement  de  liaison). 

M : I 


Opernteur 


f Ecrans  de 

M 

VI SU 

M 

SX 

V visualisation 

M 

DIALOGUE 

) 

Liaison  parallele 
asynchrone  calculateur 


Liaison  bande  magnetique 


2.2  - Description  de  la  machine  M:C 

Cette  machine  permet  les  echanges  d ' informat  ions  sur  le  reseau  et  le  relais  de  ces  informations.  Elle 
se  decompose  en  : 

- machine  M : RES  (Machine  "Riseau")  permettant  1* emission  et  la  reception  des  informations  de  faqon 
synchrone.  Au  plus,  il  existe  3 machines,  1 ' af f ec tation  des  frequences  correspondantes  est  fonction 
de  1 'util isation  du  terminal, 

- machine  M : ROUT  (Machine  "Routage")  permettant,  soit  le  transfert  d ' inf ormations  sur  le  reseau,  soit 
le  relais  des  messages.  Cette  machine  assure  le  multiplcxage  et  le  demul tiplexage  des  informations  si 
cela  est  necessaire. 

Pour  assurer  son  travail,  cette  machine  exploite  des  tables  de  routage  du  reseau  qu'elle  met  a jour 
elle-meme  a chaque  intervention  qu'elle  effectue  sur  le  reseau,  ou  sont  mises  a jour  periodiquement 
par  des  messages  specialises  traites  de  faqon  particuliere. 

La  machine  M : C est  microprogramrcee  et  macroorogrammee  (gestion  du  reseau).  Les  echanges  avec  la 
machine  M : I se  font  par  "Echange  de  contexte"  du  type  "Boite  aux  lettres". 

M : C 


Mu  1 tipi exage /Demul tiplexage 


Liaison  serie  synchrone 
(Radio /Modem) 


Liaison  serie  synchrone 
(Rad io /Modem) 


Table  "Routage  Reseaux' 


Liaison  serie  synchrone 
(Radio /CMC) 


Ecrans  de 
visualisation 


Liaison  parallele 
asynchrone  calculateur 


Operateur 


Liaison  bande  magnetique 


Pour  les  machines  M : SX,  M : RFS1  et  M : RES2,  le  protocole  de  transport  des  informations  est  en  mode 
Paquet",  pour  la  machine  M : RES3  en  mode  "Message". 
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3 - ORGANISATION  FONCTIONNELLE  DU  TERMINAL  - CONDITIONS  D * ENVIRONNEMENT 


3.1  - Organisation  fonctionnelle  du  terminal 

La  figure  4 donne  1 'organisation  fonctionnelle  du  terminal.  Ce  terminal  est  realise  A partir  d'un  micro- 
processeur  rapide  utilisant  les  plus  rAcents  developpements  technologiques  (Circuits  de  la  famille  AMD  2900) 
Son  temps  de  micro-instruction  est  de  300  nanosecondes.  Le  coupleur  minibande  est  construit  autour  d'un  LSI 
MC  6800  ; il  peut  effectuer  des  sauts  et  recherches  de  fichiers.  Le  microprocesseur  central  peut  supporter 
de  1 A 4 ecrans. 

Enfin,  il  est  interessant  de  noter  les  volumes  de  programme  (4  K mots  en  memoire  morte  pour  le  micro- 
logiciel,  4 K mots  en  memoire  banale  pour  le  macrologiciel,  8 K restant  A la  disposition  de  1 'utilisateur) . 
Ce  dernier  point  montre  l'interet  de  la  solution  par  rapport  A une  solution  calculateur. 

3.2  - Conditions  d ' environnement 

Le  terminal  est  conqu  pour  etre  install#  sur  vehicule  tout  terrain  ; le  materiel  est  done  realise  pour 
satisfaire  A 1 1 environnement  : 

- mecanique  (vibrations  5 g de  10  A 500  Hz  ; secousses  25  g,  6 ms  ; chocs  30  g,  11  ms), 

- climatique  (-  25°C  ; + 55°C  ; 40°C  95  1 d’humidite  relative  ; stockage  - 40*0,  ♦ 70°C,  brouillard 
salin).  Pour  ameliorer  la  dissipation  thermique,  les  cartes  sont  equipees  d'un  bus  thermique, 

- perturbations  radioelectriques  (conduction  et  rayonnement  MAT  7291  ; suscept ibil i te  MIL  STD  462). 

Deux  types  d ' integration  des  materiel s jont  presentes  figure  3. 

4 - LE  LOGICIEL  DU  TERMINAL  (la  figure  5 donne  son  architecture) 


4.1  - Presentation 

Le  logiciel,  construit  autour  d'un  moniteur  temps  reel,  se  compose  d'une  partie  microprograramee 
implantee  dans  la  mAmoire  morte  et  d'une  partie  macroprogrammee  situAe  dans  la  memoire  vive  banale. 

Le  microprogramme  est  execute  par  le  microprocesseur  (micro-instructions) . 

Les  instructions  macroprograramees  (primitives)  sont  interprAtAes  par  le  logiciel  microprogram!!# . 

Le  logiciel  macroprogramme  est  lui-meme  const itue  d'un  logiciel  systeme  livr#  avec  le  terminal  et  d'un 
logiciel  raacroprogramro#  specifique  A 1 ' appl icat ion  A la  charge  de  1 'utilisation. 

Le  macrologiciel  systeme  peut  exister  en  plusieurs  versions  qui  seront  chargees  A 1 ' initial isation  du 
terminal,  soit  par  le  calculated",  soit  par  la  bande  magnet ique  pour  le  terminal  autonome.  Il  assure  : 

- la  gestion  des  transferts  sur  le  canal  Bande  Magnetique, 

- la  gestion  des  Achanges  sur  le  canal  calculateur, 

- la  gestion  des  messages  CMC  (observateurs) , 

- la  gestion  du  graphe  des  reseaux  de  transmissions  (deux  frequences  simultanees)  et  le  formatage  des 
messages  et  le  declenchement  des  transferts, 

- 1 ' initialisation  des  taches  systAme. 

4.2  - Primitives 

Le  macroprogramme  est  Acrit  A partir  d'un  langage  const itue  de  primitives  ou  instructions  qui  possedent 
les  deux  proprietes  suivantes  : 

- 1 * instruction  peut  avoir  plusieurs  adresses  d'opArandes  (machine  A plusieurs  adresses), 

- 1 ' instruction  est  de  longueur  variable. 

Outre  les  instructions  du  moniteur,  de  gestion  des  files  en  memoire  de  travail  et  de  calculs,  le 
terminal  possede  deux  families  d ' instructions  qui  permettent  de  traiter  avec  une  tres  grande  souplesse  : 

- la  gestion  de  la  visualisation  (ecrans), 

- les  transferts  (controles  du  reseau  sous  procedure  de  transmission). 

4.3  - Gestions  des  ecrans 

Ce  paragraphe  montre  l'interet  des  instructions  de  visualisation. 

Le  logiciel  du  terminal  realise  la  creation  ou  la  modification  dynamique  des  elements  de  la  liste  de 
visual isat ion  A partir  : 

- soit  des  resultats  et  des  ordres  fournis  par  le  macroprogramme  d 'application, 

- soit  des  informations  fournies  par  l'operateur  (clavier). 

4.3.1  - Gestion  de  l'Acran 

L'Acran  est  structure  en  zones  (16  maximum)  gerees  de  fa^on  independante  (on  a done  1 'equivalent  de 
16  ecrans).  Dans  chaque  zone  sont  presentees  des  informations  sous  la  forme  de  chaines  de  caractAres  qui 
peuvent  etre  de  deux  types  : 

- des  textes  invariables  proteges  non  accessibles  A l'operateur, 

- des  variables  qui  sont  des  champs  de  caractAres  modifiables  par  l'operateur  ou  le  programme 
d'application.  Dans  certains  cas,  elles  peuvent  etre  protegees  par  le  programme  et  ne  sont  plus 
accessibles  A l'operateur. 


18-4 


Les  chatnes  de  caracteres  gone  rasserablees  en  grille  qui  peuvent  etre  affichees  dans  leg  zones. 

4.3.2  - Gestion  des  zones 

Les  zones  sont  rec tangulaires  et,  a un  instant  donne,  le  guide  de  frappe  de  l'operateur  ne  peut  se 
trouver  que  dans  une  seule  zone  et  ne  peut  en  sortir  que  par  action  du  macroprogramme  d'application. 

Dans  chaque  zone,  le  progranme  d'application  a la  possibility  d'introduire  une  grille  et  une  seule. 
Les  zones  sont  ddfinies  en  dynaraique  par  le  macroprogramme  d'application  au  moyen  d'une  primitive. 

4.3.3  - Actions  entreprises  sur  les  images 


Les  actions  sont  developpees  A partir  des  instructions  du  macroprogramme  d'application  : 

- visualisation  d'une  grille  dans  une  zone, 

- mise  A jour  des  variables  de  la  zone, 

- envoi  des  variables  d'une  zone, 

- effacement  d'une  zone, 

- effacement  des  variables  d'une  zone, 

- modifications  des  attributs  relatifs  a des  variables  d'une  zone, 

- tests  sur  les  variables  d'une  zone, 

- visualisation  d'une  chaine  de  caractAres  dans  une  variable, 

- gestion  d'un  pointeur  d ' exploration  des  variables  d'une  zone. 

Les  instructions  de  visualisation  conferent  done  a l'operateur  du  terminal  autonome,  en  dehors  de 
toute  connexion  A un  calculateur,  des  traitements  puissants  d' image. 

5 - GESTION  DES  TRANSMISSIONS 

5.1  - Presentation  du  logiciel  correspondant 

Le  logiciel  "Gestion  des  Transmissions"  est  realise  en  deux  parties  : 

- microprogramnee  (en  memoire  morte)  banalisee  et  independante  du  deploiement  des  terminaux  en  rAseau 
centralise  ou  non, 

- macroprogranmee  systeme  specifique  A l'utilisation  du  terminal  (PC,  DL,  BATTERIE). 

Le  microprogramrae  traite  : 

- la  gestion  d'emission  dans  les  phases, 

- la  synchronisation  emission/reception, 

- les  compactage  et  decompactage  des  messages, 

- la  reconstitution  des  messages, 

- la  validity  d'un  message  (structure,  CRC) . 

Le  macroprogranme  travaille  sous  controle  du  moniteur  et  est  done  libAre  des  problSmes  de  temps  rdel . 
Les  deux  fonctions  essentielles  assurees  sont  : 

- la  fonction  gestion  du  rAseau  et  memorisation  de  l'etat  du  reseau, 

- la  fonction  relayage  (aiguillage,  fonction  realisAe  A partir  des  informations  stockees  par  la 
fonction  gestion  du  reseau) . 

5.2  - Principes  de  la  procedure  de  transmission 

La  procedure  employee  a pour  but  d'eviter  les  risques  d ' interference  en  depit  de  l'utilisation  d'une 
frequence  commune,  tout  en  assurant  un  maximum  de  discretion  en  ce  qui  concerne  les  ymissions. 

5.2.1  - Type  de  transmission 

Les  echanges  entre  les  abonnes  sont  du  type  multiplexage  temporel  et  permettent  la  liaison  entre  un 
maitre  et  un  ou  plusieurs  esclaves  (par  exemple  en  reseau  centralisA  PC  -*-B  ; en  ryseau  decentralisA 
DL-»-B).  Le  temps  d'un  echange  entre  un  maitre  et  un  esclave  est  appele  phase. 

5.2.2  - Notion  de  relais 

En  car  de  mauvaise  propagation  empechant  la  liaison  directe,  un  abonny  esclave  peut  prendre  le  relais 
d'un  abonne  maitre.  L'abonne  relais  se  substitue  3 l'abonne  maitre  pour  etablir  la  liaison  avec  T'abonnC 
relaye.  Un  message,  Amis  par  le  maitre  pour  l'abonny  relaye  dans  le  crAneau  de  temps  d'un  abonny  relais, 
sera  reemis  par  celui-ci  dans  le  crAneau  de  temps  de  l'abonny  relaye. 

5.2.3  - Notion  de  maitre  et  d'esclave 

Vis-SI-vis  d'une  liaison,  il  existe  toujours  un  abonne  maitre,  c'est-A-dire  libre  d'emettre  le  premier 
dans  la  phase,  l'autre  abonne  est  esclave  car  il  ne  peut  emettre  que  si  le  maitre  ne  dit  rien. 

En  liaison  relais,  l'abonne  maitre  delAgue  ses  pouvoirs  A un  abonny  relais. 
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5.2.4  - Notion  de  message 

Les  messages  operationnels  transitant  dans  le  reseau  sont  precedes  d'un  preambule  de  service  permettant 
au  raaitre  de  donner  des  directives  et  3 l'esclave  de  retourner  des  informations.  Ces  messages  peuvent  etre 
decoupes  en  paquets,  chaque  paquet  etant  accompagne  de  ses  propres  informations  de  controle. 

Par  ailleurs,  pour  des  raisons  de  saturation  et  de  discretion,  un  message  correctement  re;u  peut  ne  pas 
faire  X'objet  d'un  accuse  de  reception. 

Enfin,  un  message  de  service  particulier  permet  d'assurer  un  contrSle  de  flux  sur  le  reseau. 

6 - MAINTENANCE 

Le  terminal  est  concju  pour  satisfaire  3 une  politique  de  maintenance  dont  les  objectifs  sont  les 
suivants  : 

- temps  d'indisponibilite  operationnelle  limite  (decoupage  en  sous-ensembles  pouvant  etre  isoies  pour 
la  recherche  de  la  panne)  3 une  demi-heure  maximum, 

- automatisation  de  la  recherche  de  la  fonction  en  panne  3 1'intArieur  d'un  sous-ensemble  (ce  qui 
impose  des  fonctions  enfichables)  ainsi  que  de  la  rehabilitation, 

- automatisation  du  controle  des  lots  de  rechanges  (dAstockage  rapide), 

- conception  des  plaquettes  3 circuits  imprimAs  enfichables  orientAe  pour  la  recherche  du  composant  en 
panne  avec  l'aide  d'un  banc  universel. 

Ces  trois  derniers  points  sont  traitAs  en  dehors  du  contexte  operationnel . 

6.1  - Maintenance  premier  niveau 

Ce  niveau  permet  3 l'operateur  de  s'assurer  du  bon  fonctionnement  de  son  terminal. 

Le  terminal  possSde  en  mAmoire  morte  un  micrologiciel  de  maintenance  qui  permet  de  s'assurer  du  fonc- 
tionnement global  du  microprocesseur , de  la  mAmoire  morte,  des  mAmoires  vives  3 1' initialisation  du 
terminal . 

En  transparence  avec  le  fonctionnement  opArationnel , le  microprocesseur  surveille  le  fonctionnement  du 
bus  (sAquencement,  donnAes)  et  des  coupleurs  (mot  d'etat,  validity  des  informations).  La  carte  systeme  par 
sa  surveillance  du  matAriel,  independamnent  du  microprocesseur,  peut  supplier  3 sa  defaillance. 

Les  resultats  sont  transmis  sous  forme  synthAtique  : , 

- soit  3 un  panneau  centralise, 

- soit  par  un  mot  d'Atat  utilisable  par  le  macroprogramme  utilisateur. 

Le  aoniteur  TV  et  le  clavier  possedent  un  autoteat  intAgre  permettant  3 tout  moment  3 l'operateur  de 
controler  son  poste  de  dialogue.  Pendant  le  test,  le  moniteur  ou  le  clavier  sont  dAconnectAs  de  leur 
coupleur  respectif,  ce  qui  permettra  des  levers  de  doute  pour  le  deuxiAme  niveau. 

6.2  - Maintenance  deuxiAme  niveau 

Ce  niveau  correspond  3 la  recherche  du  sous-ensemble  en  panne.  Ckitre  les  tests  prAvus  au  premier  niveau 
qui  permettant  au  technician,  3 partir  d’un  guide  de  localisation,  de  trouver  la  panne,  le  terminal 
possAde  de  plus,  en  mAmoire  morte,  des  interfaces  qui  permettent  de  mettre  en  place  des  macroprogrammes  de 
test  : 

- des  liaisons  MODEM  et  CMC  par  rebouclage, 

- de  la  liaison  CALCULATE UR  (dans  ce  cas,  c'est  le  calculateur  qui  est  mattre  du  test), 

- de  la  liaison  Bande  MagnAtique, 

- compl Ament air es  de  certaines  fonctions. 

6.3  - Maintenance  troisiAme  niveau 

C'est  la  recherche  de  la  fonction  en  panne  3 1'intArieur  du  sous-ensemble  avec  possibility  d'arriver 
jusqu'3  la  plaquette. 

Pour  cela  chaque  sous-ensemble  a AtA  conqu  pour  Stre  testy  par  un  banc  universel  progransnA  en  langage 
ATLAS. 

Le  banc  a accAs  au  sous-ensemble  par  des  prises  de  mesure. 

Pour  le  test  du  microprocesseur,  le  banc  se  substitue  au  panneau  technique  manuel,  ce  qui  lui  permet  de 
tester  toutes  les  micro-instructions  de  l'unity  centrale.  Pour  le  contrSle  de  son  interface  Entrye-Sort ie, 
le  banc  a accis  au  bus,  il  peut  done  simuler  toutes  ces  configurations. 

Pour  le  test  des  coupleurs,  le  mode  d ' intygration  des  sous-ensembles  (caissons  enfichables)  permet  au 
banc  d'accAder,  d'une  part  au  bus,  d'autre  part  aux  interfaces  d'Entryes-Sorties  des  coupleurs.  II  peut 
done,  de  maniire  automatique,  rechercher  un  coupleur  en  panne. 

II  faut  noter  que  dans  certains  cas,  pour  faciliter  les  mesures,  les  fonctions  ont  AtA  amAnagAes  pour 
pouvoir  etre  pilotAes  par  le  banc  (synchronisation  externe  des  fonctions  par  le  banc). 

Remerciements  : 

Le  terminal  dAcrit  ici  a Ate  realise  sous  I'Agide  de  la  DTAT/Section  d'Etudes  et  de  Fabrications  des 
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RESUME 


Une  quatrieme  generation  d'Aquipements  de  bord  fait  actuellement  son  apparition  dans  laquelle  le 
traitement  des  signaux  video  se  fait  5 l'aide  de  logique  programmee,  ce  que  permet  1‘utilisation  des  micro- 
processeurs.  De  plus,  le  developpement  des  semi -conducteurs  UHF  de  puissance  permet  une  transistorisation  de 
en  plus  poussee  des  equipements. 

Les  equipements  de  bord  TACAN,  dont  la  tAche  est  d'extraire  du  signal  regu  des  balises  au  sol  les 
informations  de  re levement  et  de  distance,  bAnAficient  parti culiArement  de  ces  nouvelles  technologies.  Le 
passage  de  la  logique  cablee  A la  logique  programme  permet  les  ameliorations  suivantes  : 

- lissage  efficace  des  informations  par  boucles  d'asservissement  auto-adaptatives,  condition  indispensable 
pour  la  navigation  sur  but  ; 

- calcul  de  la  navigation  sur  but  elle-meme. 

Le  logiciel  est  partage  en  quatre  parties,  trois  parties  de  traitement  proprement  dit  (azimut,  dis- 
tance, navigation)  et  une  partie  moniteur  de  gestion  tenant  compte  des  diffArents  modes  de  fonctionnement. 

Les  transistors  de  puissance  UHF  permettent  la  realisation  d1 equipements  de  bord  compietement  tran- 
sistorises dont  le  principal  avantage  est  la  reduction  sensible  de  la  puissance  dissipee  rendant  inutile 
leur  refroidissement  par  air  force. 

LMT  realise  actuellement  un  equipement  de  bord  TACAN  utilisant  ces  nouvelles  techniques. 

INTRODUCTION 


Apres  trois  generations  d1 equipements  de  bord  ou  se  sont  succedees  les  technologies  A tubes,  puis 
A transistors,  avec  lesquelles  les  traitements  des  signaux  etaient  de  type  analogique,  enfin  A circuits 
integres  avec  des  traitements  du  type  numerique,  une  quatrieme  generation  fait  son  apparition  ou  la  logique 
programmee  vient  remplacer  la  logique  cablee  de  la  3Ame  generation.  C'est  avec  Vapparition  des  microproces- 
seurs  et  le  developpement  des  memoires  mortes  (ROM)  et  des  memoires  vives  (RAM)  A semi -conducteurs  qu'est 
nee  l'idee  qu'on  pouvait  enfisager  d'utiliser  la  logique  programme  pour  effectuer  les  traitements  relati- 
vement  simples  des  signaux  TACAN.  La  souplesse  de  la  logique  programmee  permettra,  comme  on  le  verra,  une 
nette  amelioration  du  lissage  des  informations  TACAN  mesurees,  condition  imperative  si  Ton  veut  faire  de 
la  navigation  de  zone  avec  le  TACAN.  De  plus,  la  capacite  de  calcul  du  microprocesseur  est  largement 
suffisante  pour  faire,  en  plus,  les  calculs  de  changement  de  coordonnAes  pour  la  navigation  sur  un  but 
deporte  par  rapport  A la  balise. 

Paralieiement  au  developpement  des  microprocesseurs,  les  efforts  sont  poursuivis  pour  augmenter  les 
puissances  crAtes  des  transistors  UHF,  ce  qui  permet  des  maintenant  d’eiiminer  les  derniers  tubes  encore 
utilises  dans  l'emetteur  par  un  amplificateur  A transistors.  L'avantage  qui  en  rdsulte  est  une  reduction 
sensible  de  la  puissance  dissipee  et  la  stabilite  dans  le  temps  de  la  puissance  HF  crAte  de  sortie.  Cette 
baisse  de  consonmation  des  equipements  va  permettre  leur  installation  A bord  sans  refroidissement  par  air 
force  et  soulager  d'autant  la  genera trice  de  bord. 

TRAITEMENT  VIDEO  PAR  MICROPROCESSEUR 


Rappel  du  traitement  A effectuer 


Le  signal  video  A traiter  est  obtenu  apres  amplification  et  detection  et  est  rAgulA  en  niveau  par 
le  CAG  dans  le  rAcepteur  pour  etne  ensuite  decode  (fig.  1).  II  est  constituA,  d'une  part,  d'impulsions 
gaussiennes  de  3, 5, us  de  largeur  A mi -ampl i tude , distribuAes  de  fagon  alAatoire  du  rythme  de  2700  par  secon- 
de,  d'autre  part,  ties  deux  types  de  trains  d'une  dizaine  d'impulsions  rapprochAes  constituant  les  references 
du  relAvement,  les  references  dites  principales  A la  recurrence  15  Hz,  les  references  dites  auxiliaires  A 
la  recurrence  135  Hz.  L"ensemble  des  impulsions  est  module  en  amplitude  par  2 signaux  sinusoTdaux  A 15  Hz 
et  A 135  Hz,  chacun  au  taux  d'environ  20*  (fig.  2). 

Pour  obtenir  1 'information  de  relAvement,  le  traitement  A effectuer  consiste  A decoder  les  2 types 
de  references,  A extraire  chaque  modulation  et  A mesurer  en  terme  de  phase  15  Hz  l'Acart  entre  la  reference 
et  le  passage  positif  par  z6ro  de  la  sinusoTde  de  modulation. 

Pour  obtenir  1 ' information  de  distance,  le  traitement  consiste  A extraire  des  impulsions  alAatoires 
celles  qui  sont  les  rAponses  et  qui  sont  les  seules  qui  soient  synchrones  des  interrogations,  puis  de  deter- 
miner l'Acart  de  temps  t mesurA  par  une  horloge  A quartz  sAparant  la  rAponse  de  1 'interrogation  correspon- 
dante  d’ou  1'on  dAduit  la  distance  : p « ct  (fig.  3). 


Traitement  de  la  distance  par  logique  programme 

En  logique  cSblbe,  le  traitement  de  la  distance  consiste  4 asservir,  en  la  centrant  sur  1' impulsion 
reponse,  une  porte  de  lO.us  environ  gbnbrbe  par  un  compteur  alimentb  par  une  horloge  4 quartz  et  dbclenchb 
par  1' interrogation.  L'asservissement  est  du  second  ordre  pennettant  ainsi  une  mesure  de  distance  sans  erreur 
en  defilement.  II  est  precede  d'une  phase  d'acquisition  oO  la  porte  explore  successivement  les  temps  de 
reception  des  impulsions  jusqu'au  moment  oG  il  rencontre  les  impulsions  reponses  synchrones  des  interroga- 
tions pendant  quelques  cycles  consecutifs. 

En  logique  programmee,  on  utilise  le  meme  compteur  dont  on  memorise,  dans  une  memoire  vive  contrfilbe 
par  le  microprocesseur,  les  etats  au  moment  de  la  reception  des  impulsions.  Ces  etats  sont  des  mots  de  15  bits 
et  le  microprocesseur  recherche  l'identite  des  mesures  de  2 cycles  consecutifs  pour  extraire  les  impulsions 
reponse  : c'est  la  phase  d'acquisition.  En  phase  poursuite,  la  porte  de  poursuite  est  generee  par  un  compara- 
teur  de  bits  relie  au  compteur  qui  regoit  du  microprocesseur  1 'information  de  1 'instant  presume  de  reception 
de  la  reponse,  instant  oG  le  compteur  de  mesure  contiendra  la  valeur  de  la  distance.  Le  calcul  de  l'instant 
est  obtenu  4 partir  d'un  systeme  d'6quations  aux  differences  qui  est  1 'equivalent  en  logique  programmee  d'un 
asservissement  du  second  ordre. 

Traitement  de  l'azimut  en  logique  programmee 

En  logique  cSbiee  comme  en  logique  programmee,  1'horloge  de  mesure  d'azimut  est  gen6ree  par  un 
oscillateur  asservi  sur  les  trains  de  references  principals  et  auxiliaires  decodes.  Un  detecteur  de  Crete 
extrait  la  modulation  composite  des  impulsions  qui,  apr§s  2 filtrages,  fournit  les  deux  signaux  sinusoTdaux 
de  mesure  15  Hz  et  135  Hz.  Une  impulsion  est  creee  pour  chaque  passage  positif  par  zero  de  ces  signaux. 

En  logique  c4biee,  on  choisit  l'impulsion  4 135  Hz  la  plus  voisine  de  celle  du  15  Hz  qui  transfere 
le  contenu  du  compteur  de  mesure  de  reievement  alimente  par  1'horloge  de  mesure  et  declenche  par  l'impulsion 
15  Hz  de  reference.  La  qualite  de  la  mesure  depend  done  essentiellement  de  la  qualite  du  filtrage  des 
modulations. 

En  logique  programmee,  on  utilise  le  meme  compteur  de  mesure  dont  on  envoie  les  contenus  (mots  de 
12  bits)  au  microprocesseur  au  moment  de  l'arrivee  des  impulsions  issues  des  sinusoTdes  15  Hz  et  135  Hz  de 
modulation.  Le  traitement  va  consister  a determiner  l’impulsion  135  Hz  la  plus  voisine  de  celle  du  15  Hz 
et  4 effectuer  des  calculs  sur  les  reievements  mesures  a partir  d'un  systeme  d'equations  aux  differences 
(comme  pour  la  distance)  pour  obtenir,  14  aussi , un  asservissement  du  second  ordre  qui  va  parfaire  le  fil- 
trage des  modulations. 

AVANTAGES  ET  POSSIBILITES  SUPPLEMENTAIRES  OFFERTS  PAR  Lfl  LOGIQUE  PROGRAMMEE 
Boucles  d' asservissement  auto-adaptatives 

Dans  le  traitement  de  la  distance  comme  dans  celui  du  relAvement,  on  a vu  qu'on  effectuait  des  calculs 
4 partir  d'un  systeme  d'equations  aux  differences.  On  calcule,  4 chaque  echantillon,  la  difference  entre 
valeur  estim6e  et  valeur  mesurbe  en  utilisant  le  systeme  d'equations  suivant  : 

Erreur  = Valeur  mesurbe.,  - Valeur  estimee 
n n n 

Vitessen  + ^ = Vitessen  + (K?  x ErreurJ 

Valeur  estimbe„  . , = Valeur  estimee„  + K,  x (Erreur  + Vitesse„  . .) 

n + i n l ' n n + i 

La  valeur  mesuree  4 1 ’echantillon  n permet  de  calculer  la  vitesse  estimee  a 1 'echantillon  n + 1,  et 
la  valeur  estimee  4 l'echantillon  n + 1.  On  montre  facilement  que  ce  systeme  de  3 equations  definit  une 
relation  entre  les  valeurs  estimbes  et  les  valeurs  mesurbes  aux  instants  n + 1 et  n - 1 caractbristique  d'un 
systeme  du  second  ordre. 

En  logique  cSblbe,  on  a vu  que  pour  la  distance  le  meme  traitement  est  effectub,  mais  les  coeffi- 
cients ..j  et  l<2  sont  determines  une  fois  pour  toutes.  Or  ces  valeurs  sont  un  compromis  pour  obtenir  un 

lissage  acceptable  n'entrainant  pas  d'blongations  trop  importantes  de  l'erreur  au  cours  de  la  stabilisa- 
tion de  l'asservissement  (fig.  4).  La  mesure  reste  ainsi  encore  sensible  au  bruit  qui  est  important  sur- 
tout  au  seuil  de  sensibilitb  du  rbcepteur  et  parti culibrement  en  relbvement.  II  serait  done  souhaitable 
d’utiliser  deux  ou  trois  jeux  de  coefficients,  l'asservissement  cornmengant  avec  le  jeu  offrant  la  moins 
bonne  stabilitb,  mais  la  moindre  elongation  pour  terminer  avec  les  coefficients  permettant  le  lissage  le 
plus  efficace  (fig.  5). 

II  est  possible  d'utiliser  ces  boucles  auto-adaptatives  en  logique  cSblbe,  mais  c'est  au  prix  d'une 
trop  grande  complication  des  circuits.  En  outre,  toute  modification  des  valeurs  des  coefficients,  entraine 
une  modification  importante  des  circuits. 

En  logique  programmee,  au  contraire,  doubler  ou  tripler  le  jeu  de  coefficients  n'entraine  qu'un 
accroissement  du  nombre  destructions  du  programme.  II  faut  remarquer  bgalement  la  souplesse  du  systeme 
puisque  modifier  la  valeur  des  coefficients  n'entraine  que  la  reprog raumati on  d'une  mbmoire  morte. 

En  outre,  la  precision  de  l'asservissement  dbcoulant  en  particulier  des  mesures  sur  les  vitesses 
peut  Stre  tres  grande  en  logique  programmee.  En  effet,  en  logique  cSblbe,  le  pas  du  compteur  de  vitesse 
est  limite  pour  ne  pas  compliquer  les  circuits  (en  distance,  par  exemple,  les  increments  sont  de  l'ordre 
de  50  noeuds)  alors  qu'en  logique  programmee,  la  resolution  en  vitesse  est  adaptbe  au  defilement  et  peut 
etre  ainsi  tres  grande  aux  faibles  vitesses  (pour  reprendre  le  mbme  exemple  de  la  distance,  on  peut  obtenir 
facilement  une  resolution  de  l'ordre  du  noeud).  II  en  rbsulte  l'avantage  qu'en  cas  de  perte  de  l'information, 
le  systeme  peut  passer  en  mbmoire  dynamique  avec  de  faibles  derives. 


' 
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Le  lissage  des  informations  reievement  et  distance  TACAN  ainsi  obtenu  est  indispensable  si  Ton  veut 
faire  les  calculs  permettant  la  navigation  sur  un  but  deporte  par  rapport  4 la  balise  (ou  la  navigation  de 
zone).  On  montre  facilement,  en  effet,  qu'avec  certaines  configurations  geometriques,  les  fluctuations  des 
informations  TACAN,  memes  faibles,  entrainent  des  fluctuations  tres  importantes  des  coordonnees  calculSes. 

Possibilite  de  calcul  de  navigation 

Lorsqu'il  y a presence  dans  le  meme  equipement  de  navigation  d'un  moyen  de  calcul  et  des  coordonnees 
polaires  par  rapport  4 une  balise  au  sol,  il  est  naturel  d'effectuer  les  calculs  de  changement  de  coordonnees 
sur  un  but  dont  on  aura  entre  les  coordonnees  par  rapport  4 la  meme  balise  (fig.  6). 

Py  et  9y  sont  les  coordonnees  de  la  balise  TACAN  par  rapport  4 V avion. 

Pq  et  Oq  sont  les  coordonnees  du  but  par  rapport  4 la  balise  TACAN. 

Pg  et  0g  sont  les  coordonnees  du  but  par  rapport  4 1‘avion. 

Les  equations  4 resoudre  sont  evi dentes  : 

Pg  COS  0g  = py  COS  0y  + Pq  COS  0q 

pg  sin  0g  = py  sin  0y  + pQ  sin  @g 
On  en  deduit  : 


PB 


■V* 


COS20d 


sin20„ 


0g  = Arc  tg 


PB  sin  0B 

Pg  COS  0g 


Les  algorithmes  effectuant  ces  calculs  sont  bien  connus. 

On  peut  calculer  les  quantites  sin  0 et  cos  @ par  programme  ou  plus  simplement  les  obtenir  4 l'aide 
d'une  memoire  sinus,  ce  qu'i  permet  de  reduire  sensiblement  le  temps  de  calcul. 

Si  l'on  entre  egalement  Tangle  d'une  route  @ 4 suivre  passant  par  le  but  (fig.  6),  les  operations 
suivantes  sont  aussi  aisement  effectuees  : r 

- calcul  de  la  deviation  de  la  route  4 suivre  : eD  - e 

B r 

- calcul  de  1'ecart  lateral  4 la  route  1 


- calcul  de  la  distance  orthogonal e au  but  d. 

Un  exemple  de  realisation  4 LMT 

Pour  juger  les  avantages  du  traitement  video  par  logique  programme  des  informations  TACAN,  le  STTA 
nous  a aide  a realiser  et  a tester  en  vol , avec  l'aide  du  CEV,  un  prototype  de  video  TACAN  a microprocesseur. 
Cette  video  est  installee  sur  deux  cartes  imprimees  en  lieu  et  place  des  circuits  video  4 logique  cabiee 
d'un  equipement  TACAN  de  bord. 

Le  logiciel  est  divise  en  4 parties  : 

- une  partie  reievement, 

- une  partie  distance, 

- une  partie  affichage  et  controle  des  coordonnees  du  but  deporte  et  calcul  de  navigation, 

- une  partie  moniteur  de  gestion. 

Le  moniteur  classe  et  repartit  dans  le  temps  les  differents  traitements  4 effectuer  en  tenant  compte 
des  differents  modes  de  fonctionnement  du  TACAN  de  bord  : reception  seule  (sans  distance),  normal,  air-air 
(distance  seulement),  et  des  differents  modes  d'utilisation  du  system®  (coordonnees  TACAN  ou  coordonnees 
du  but  deporte). 

Le  microprocesseur  du  type  N MOS  est  un  8 bits.  II  est  couple  4 une  memoire  vive  (RAM)  de  256  octets. 
Le  programme  reievement  conti ent  650  instructions  et  s'execute  en  3,5  ms. 

Le  programme  distance  contient  560  instructions  et  s'execute  en  1,5  ms. 

Le  programne  calcul  de  navigation  contient  700  instructions  et  s'execute  en  80  ms.  II  faut  signaler 
que  le  traitement  est  totalement  effectue  par  programme  et  que  ce  traitement  serait  reduit  a quelques  ms  si 
Ton  utilisait  des  memoires  sinus. 

L'ensemble  des  programmes,  y compris  le  moniteur,  contient  2500  instructions  representant  4800 
octets  repartis  sur  5 memoires  mortes  programmables  (PROM)  de  1024  octets  chacune. 
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Du  fait  des  dimensions  importantes  des  composants,  tels  que  le  microprocesseur,  les  memoires  vives 
et  mortes,  les  memoires  tampon  d'entrees-sorties,  les  dimensions  des  circuits  sont  3 peu  pr#s  les  mSmes  en 
logique  programmee  qu'en  logique  cablee  (fig.  7 et  8). 

La  consommation  sur  les  tensions  d' al imentation  est  un  peu  plus  importante  qu'avec  la  logique  cSbiee 

(qui  utilise  la  logique  TTL  LS)  bien  que  le  microprocesseur  soit  en  technologie  N MOS,  mais  les  organes 

d'entrees-sorties  et  les  memoires  mortes  programmables  actuellement  disponibles  sur  le  march#  consomment 
beaucoup.  On  peut  esperer  que  des  progres  seront  faits  prochainement  dans  ces  domaines. 

L'importance  de  la  mise  au  point  de  la  programmation  est  evidente  dans  la  mesure  ou  l'on  cherchera 

a reduire  au  maximum  la  longueur  du  programme,  ce  qui  permettra  de  gagner  3 la  fois  du  temps  et  des  memoires 

et  done  de  minimiser  le  nombre  de  circuits  et  la  consommation.  D'oD  l'emploi  du  langage  assembleur  ou,  sinon, 
d'un  langage  ayant  reellement  un  tres  faible  taux  d'expansion. 

Les  informations  numeriques  de  distance  et  de  relevement  sont  directement  calculees  dans  le  format 
utili sable  par  les  indicateurs  TACAN  3 entries  numeriques.  L'affichage  des  coordonnees  du  but  se  fait  par 
commutation  d'un  mode  special  ou  l'une,  puis  l'autre  des  sorties  numeriques  est  incr#ment#e  3 acceleration 
constante  dans  les  deux  sens.  Comme  les  sorties  numeriques  sont  visualisees  par  1 ' indicateur,  on  arrete 
1 ' incrementation  lorsque  1 'indicateur  affiche  la  valeur  desiree  qui  est  alors  stockee  dans  une  memoire  vive 
de  la  video. 

Pour  illustrer  l'efficacite  du  lissage  apporte  par  la  logique  programmee  par  rapport  3 la  logique 
cablee,  on  a enregistre,  pour  les  2 logiques,  sur  une  table  tragante,  les  fluctuations  de  1 'information  de 
relevement  pour  deux  types  de  signaux  : signal  confortable  de  -70  dBm  (fig.  9)  et  signal  faible  de  limite 
de  portee  de  -90  dBm  (fig.  10)  generes  par  un  simulateur  de  balise  TACAN.  Les  figures  9 et  10  montrent 
1 'amelioration  considerable  apportee  par  la  logique  programmee,  puisque  dans  les  deux  cas  la  fluctuation 
est  reduite  aux  fluctuations  du  bit  le  moins  significatif  (LSB)  du  mot  numerique  de  sortie  (environ  0,1°). 

EMETTEUR  1 KW  A TRANSISTORS 

Quelques  fabricants  de  semi -conducteurs  se  sont  lances  3 la  course  aux  puissances  Crete  dans  la 
bande  L et  echanti 1 1 onnent  depuis  quelque  temps  les  transistors  capables  de  fournir  400  W Crete  dans  la 
bande  TACAN.  A l'aide  d'anneaux  hybrides,  on  peut  coupler  4 transistors,  ce  qui  permet  de  realiser  un 
emetteur  sortant  1 KW  cr§te  dans  la  bande  TACAN. 

Du  fait  des  importants  courants  crete  qui  en  resultent  (70  A crete),  des  precautions  speciales 
doivent  etre  prises  pour  obtenir  la  modulation  gaussienne  et  un  spectre  correct. 

LMT  a realise  une  chatne  d'emission  complete  comprenant  10  transistors  excites  par  le  synthetiseur 
(sortie  200  mW)  (fig.  11). 

Les  avantages  d'un  tel  emetteur  sont  evi dents  : 

- considerable  reduction  de  la  puissance  dissipee  alors  qu'en  recherche  distance  (300  impulsions  emises)  un 
emetteur  3 4 tubes  consomme  plus  de  40  W du  fait  du  chauffage  regule  des  tubes  et  des  pertes  du  g#nera- 
teur  THT,  un  emetteur  3 transistors  ne  consomme  que  5 W.  De  plus,  alors  qu'3  faibles  taux  d'emission  (cas 
le  plus  frequent  : poursuite  distance,  50  impulsions  emises)  1 'emetteur  3 tubes  consommera  une  puissance 
3 peine  reduite,  la  consommation  de  1 'emetteur  3 transistors  est  proportionnel le  au  taux  d'emission, 

- absence  de  THT  (50  V suffisent)  et  des  contraintes  qui  en  resultent  (fiabilite,  tenue  en  depression, 
etc.. .), 

- stabilite  dans  le  temps  de  la  puissance  emise  alors  que  les  tubes  vieillissent  (epuisement  de  la  cathode), 

- possibilite  de  fonctionnement  degrade  puisque  du  fait  de  l'anneau  hybride  une  defectuosite  de  l'un  des  4 

transistors  de  sortie  de  l'emetteur  ne  reduira  la  puissance  crete  de  sortie  que  de  2 dB  et  assurera  encore 

un  service  appreciable. 

DESCRIPTION  D'UN  TACAN  DE  BORD  UTILISANT  CES  TECHNOLOGIES  AVANCEES 

LMT  developpe  un  TACAN  de  bord  qui  integre  ces  nouvelles  possibilites. 

Du  fait  de  l'emetteur  et  de  1 'utilisation  de  logique  3 faible  consommation  (TTL  LS),  la  consommation 
de  ce  TACAN  de  bord  est  inferieure  a 80  W,  ce  qui  est  une  baisse  sensible  par  rapport  3 la  generation  prece- 
dente  (170  W)  et  rend  inutile  le  refroidissement  par  air  force. 

CONCLUSION 

La  miniaturisation  du  materiel  d'informatique  comme  les  memoires  et  les  microprocesseurs  vient  battre 
en  breche  certaines  idees  qui  avaient  cours  il  y a quelques  annees,  ou  l'on  imaginait  un  calculateur  de  bord 
central  et  puissant  exploitant  les  donn#es  brutes  des  differents  senseurs  devenus  incapables  du  moindre  trai- 
tement.  Avec  la  logique  programmee,  1 ' informatique  se  demystifie  peu  3 peu,  les  senseurs  qu'on  voulait  rendre 
bornes  deviennent  intelligents,  tandis  que  le  calculateur  de  bord  va  exploiter  mieux  et  avec  plus  d'efficacite 
leurs  donnees  elaborees,  tant  il  est  vrai  qu'il  est  plus  enrichissant  de  converser  avec  des  etres  intelligents 
qu'avec  des  etres  bornes. 
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FIG.  1 - Schema  synoptique  d’un  gquipement  de  bord  TACAN. 
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FIG.  2 - Signal  TACAN. 
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FIG.  4 - RGponse  du  syst&ne  a une  rampe  de  vitesse  (3150  noeuds)  en  fonction  des 
coefficients . 


FIG.  5 


Reponse  du  systSme  a une  rampe  de  vitesse  (3150  noeuds)  en  utilisant 
successivement  deux  jeux  de  coefficients. 
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G.  6 - Navigation  sur  un  but  deport#  par  rapport  a la  balise  TACAN 
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FIG.  8 - Vid#o  4 logique  programme 
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Fluctuations  comparees  de  1 'Information  de  reievement  entre  video  A 
loglque  cabiee  et  video  A logique  programme  pour  un  signal  confortable 
(-70  dBm). 
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FIG  10  - Fluctuations  compares  de  1 ' information  reievement  entre  video  3 logique 
cabiee  et  video  a logique  programme  pour  un  signal  faible  (-90  dBm). 
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SUMMARY 

This  paper  discusses  two  important  operational  problems,  the  automation  of  Command  and  Control  (C^) 
and  the  associated  data  processing  interoperability  problems.  The  CT  automation  is  beset  with  the  prob- 
lems of  flexibility  and  adaptability  and  requires  a methodology  that  allows  evolutionary  improvement  to 
the  computer  hardware  and  software  systems.  Two  primary  technologies  which  could  assist  in  the  automation 
of  C are  Software  Engineering  and  Knowledge-based  Systems.  The  Software  Engineering  technology  could 
make  the  software  system  function  more  visible,  both  to  the  programmers  and  the  staff  officers,  for  easier 
modification  as  requirements  change.  Cognitive  aids  and  Knowledge-based  Systems  can  bring  the  computer  to 
bear  on  reducing  the  complexities  of  the  C c situation  so  that  the  human  can  more  readily  grasp  the  alter- 
natives and  pay-offs  in  a battle  situation.  The  increased  degree  of  automation  in  (T  will  demand  a high 
degree  of  interoperability  among  these  C computer  systems.  Essentially  what  is  required  is  the  ability 
for  computers  to  communicate  with  other  computers  without  human  intervention  unless  the  situation  changes 
such  that  the  information  exchanged  and  the  information  paths  must  be  changed  quickly  in  a battle  situa- 
tion, in  which  case  flexibility  in  the  information  network  is  required.  The  technology  of  Distributed 
Data  Processing  attempts  to  address  this  latter  problem. 


INTRODUCTION 

This  paper's  title  might  suggest  that  it  will  be  the  typical  "Gee-Whiz,  look  what  we  computer  people 
are  going  to  have  available  to  dazzle  you  with  in  the  next  20  years."  It  could  be  an  exhaustive  expose 
of  the  higher  speed,  smaller  size,  cheaper  hardware  gadgetry  expected,  and  the  clever  things  you  will  be 
able  to  do  with  the  future  software  and  system  architectures.  I will  get  into  some  of  this  but  only  as  it 
applies  to  what  I consider  highly  important  tactical  military  problems.  Instead,  I will  be  more  problem- 
oriented  by  attempting  to  define  operational  problems  in  the  Information  Processing  area,  and  to  identify 
technological  advances  that  might  be  applied  to  these. 

My  perspective  indicates  that  two  of  the  more  important  operational  problems  associated  with  Informa- 
tion Processing  are: 

1.  The  automation  of  Command  and  Control  in  light  of  the  tremendous  increase  in  the  volume  of  data, 
the  complexity  of  the  decision  alternatives,  and  the  more  timely  responses  required;  and 

2.  The  distributed  data  processing  situation  in  light  of  the  increased  automation  and  the  need  for 
survivability  in  the  tactical  environment. 

I will  take  each  problem  in  order,  discussing  and  defining  it,  and  then  offering  some  potential 
technology  opportunities  that  might  be  applicable. 


COMMAND  & CONTROL  CENTER  AUTOMATION 

Traditionally  the  data  processing  community  has  predicted  glorious  and  wonderful  advantages  in  using 
the  latest  gadgetry  in  the  computer  world.  For  some  time  this  was  the  thing  to  do  until  the  business  and 
military  world  woke  up  to  the  fact  that  some  of  those  glorious  and  wonderful  things  were  not  occurring. 
However,  it  must  be  admitted  that  the  business  world  has  tremendously  exploited  the  use  of  computers  for 
such  applications  as  science,  accounting  and  business.  If  one  looks  into  this  one  quickly  realizes  that 
the  reason  for  success  in  these  areas  is  that  their  functions  are  not  only  fairly  routine  but  they  are 
well  defined  to  the  point  of  being  described  mathematically.  In  other  cases,  such  as  airline  reserva- 
tions, the  human  oriented  process  could  be  described  explicitly  and  an  algorithm,  however  complex,  gener- 
ated. These  are  the  type  of  applications  that  have  taken  advantage  of  the  computer. 

Once  one  gets  past  the  routine  and  the  well  defined  and  gets  into  the  higher  order  of  management 
which  involves  more  cognitive  functions,  one  finds  the  computer  little  used.  There  have  been  many 
attempts  to  extend  Management  Information  Systems  Into  supporting  these  processes  in  the  management  area 
but  most  have  fallen  short  of  expectations.  Management  Information  Systems  have  been  built  that  do  a 
fine  job  of  collecting  much  data  and  producting  reports;  however,  they  have  not  made  it  easy  for  several 
levels  of  management  to  operate  on  this  data  base  with  the  latest  operations  research  techniques  or  with 
their  own  decision  making  processes  that  have  been  developed  over  the  years  by  the  individual.  It  still 
requires  a staff  of  specialists  in  operations  research  to  apply  various  decision  modeling  techniques. 

The  average  marketeer,  salesman,  warehouse  manager  or  purchasing  agent  does  not  or  cannot  use  these  aids. 
These  aids  by  their  nature  require  the  use  of  a computer  and  we  have  not  addressed  well  the  problems 
associated  with  the  man-machine  interaction  requirements  for  using  these  aids. 

The  military  has  copied  the  business  community  in  exploiting  computers  for  business  and  administra- 
tion, and  have  led  the  business  community  in  the  application  of  computers  to  scientific  and  technical 
areas,  such  as  surveillance,  weaponry,  vehicle  guidance,  etc.  Again,  the  military  has  applied  the  comput- 
er on  well  defined  problems.  There  are  Instances  in  CSC  and  Intelligence  Analysis  in  which  procedures 
have  been  automated  very  cleverly,  still  it  is  a prerequisite  that  the  computer  has  been  applied  well  only 
where  we  have  defined  the  problem  well. 
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In  those  instances  we  seem  to  have  removed  the  flexibility  we  used  to  have  with  the  manual  or  semi- 
automatic systems.  The  humans  in  the  system  have  lost  the  ability  to  step  in  and  interject  changes  in  the 
process  or  to  view  situations  in  a different  way.  I conclude  that  we  have  not  provided  a window  into  the 
automated  process  that  would  give  the  user  the  visibility  and  insight  he  needs  to  do  things  differently 
than  planned.  You  only  have  to  look  at  such  systems  as  airline  reservations,  banking,  accounting,  and 
most  inventory  control  to  realize  how  little  control  the  user  has  over  these  systems  once  the  programmer 
has  gone  home. 

There  is  one  area  in  the  military  environment  that  as  yet  defies  satisfactory  automation,  and  that  is 
the  decision  making  process  associated  with  Command  & Control  (C&C).  The  problem  here  is  fundamental  in 
thai.  no  one  understands  the  decision  process  well  enough  to  document  it  in  a meaningful  way.  We  have  made 
attempts  at  automating  this  process  by  starting  with  the  definition  of  the  data  available  and  the  routine 
functions  performed  on  such  data.  We  have  made  considerable  progress  in  establishing  computerized  data 
bases  within  a single  C&C  Center  and  displaying  summaries  of  such  data,  but  even  here  we  are  frustrated  in 
our  attempts  to  completely  specify  the  sources  of  the  data  and  the  recipients  of  the  data. 

The  next  usual  approach  in  C&C  automation  has  been  to  attempt  to  define  those  functions  which  we  feel 
are  fairly  stable.  I suspect  that  most  of  these  functions  are  either  heavily  oriented  toward  peace  time 
operation  of  the  C&C  system  or  are  those  functions  that  by  tradition  have  been  fairly  well  defined  in  war 
time.  I think  we  are  all  aware  that  there  is  an  uneasiness  that  we  may  not  have  done  this  well  for  the 
battle  situation  and  are  desperately  looking  for  some  way  of  exercising  these  systems  to  see  if  they  can 
handle  the  situation.  At  a conference  last  year  in  Boston  on  C&C  decision  making,  a number  of  high  level 
military  strategists  who  have  participated  in  C&C  exercises  indicated  that  they  had  little  confidence  in 
the  computer  system  and  would  rather  take  a small  group  of  extremely  capable  staff  officers  and  go  off  in 
the  corner  with  a batch  of  telephones. 

Again,  I think  that  we  have  not  built  into  the  automated  C&C  process  that  necessary  window  which 
would  provide  us  the  visibility  needed  for  adaptability  in  real  situations.  I think  it  is  well  recognized 
that  we  haven't  been  able  to,  and  we  probably  should  not  try  to,  define  the  high  order  cognitive  functions 
at  the  various  staff  and  command  levels.  Both  business  management  and  military  tactical  management  are 
sufficiently  complex  and  unpredictable  that  the  automated  systems  must  adapt  to  these  cognitive  thinkers. 

What  can  be  done  about  this?  I would  suggest  the  following: 

1.  We  continue  to  automate  the  routine,  definable  functions  in  order  to  cope  with  the  amount  of  data 

and  to  reduce  manpower.  This  is  done  through  the  software  design,  development  and  testing  process,  but  we 

need  to  universally  apply  the  latest  software  engineering  methods  to  this  process. 

2.  We  provide  a good  communication  media  between  the  C&C  user  and  the  software  developer.  We  organ- 

ize and  discipline  this  software  development  process  through  software  engineering  techniques,  and  finally 
we  bring  this  software  development  process  to  the  door  step  of  the  user. 

3.  We  build  windows  into  the  automated  functions  so  the  user  can  see  what  he  did  when  he  automated 

his  system  and  how  it  was  done.  These  windows  are  achieved  by  various  means  working  in  consort,  including 
man-machine  interaction  techniques  and  user  oriented  software  documentation  that  is  understandable  and 
utilitarian  for  the  user. 

4.  We  give  the  user  some  special  programming  tools  that  allow  him  to  modify  programs  in  real  time  as 
his  functional  requirements  change. 

5.  We  develop  cognitive  aids  and  deliver  knowledge  based  systems  specifically  tailored  to  higher 
order  Command  and  Control  Analysis  and  Decision  functions. 

The  two  primary  technologies  we  look  toward  are  Software  Engineering  and  Knowledge-based  Systems. 

The  first  addresses  the  total  process  of  software  system  specification,  design,  programming,  testing, 
documentation,  maintenance,  and  modification.  The  second  addresses  the  automation  tools  needed  by  the 
Command  Center  Staff  to  carry  out  those  ill-defined  tasks  and  swiftly  react  to  unanticipated  situations. 


DISCIPLINING  THE  SOFTWARE  PROGRAMMING  ENVIRONMENT 

In  Munich,  in  1968,  the  idea  of  putting  rigor  and  discipline  into  the  Software  programming  process 
was  first  publicly  defined  and  introduced  --  it  was  called  Software  Engineering.  Since  that  time  a revolu- 
tion has  taken  place  in  the  way  we  design,  program  and  test  software  systems.  You  are  all  aware  of  such 
techniques  as  Structured  Programming,  Chief  Programmer  Teams,  Programming  Support  Libraries,  Design 
Languages,  Top  Down  Design,  Path  Testers,  Validators,  Verifiers,  and  many  more.  The  technology  is  well 

along  and  much  is  available  today  to  finally  control  the  programming  process.  Given  a good  system  specifi- 

cation, a software  system  can  be  well  defined,  programmed,  tested  and  transitioned  to  the  user  in  such  a 
condition  that  it  can  be  well  maintained  and  modified  --  all  done  in  a well  managed  manner.  It  has  been 

done,  and  more  of  the  software  systems  will  be  done  this  way  — it's  just  a question  of  time  during  which 

the  training,  management  policies  and  procedures  can  catch  up  to  the  technology.  The  result  of  this  pro- 
cess is  a set  of  well  defined,  structured,  and  documented  software  that  is  capable  of  being  understood  by 
both  the  user  and  anyone  who  later  comes  along  to  modify  the  system. 

This  Is  a beginning  to  providing  a window  Into  the  software  so  that  the  user  can  adapt  the  software 
as  necessary.  The  disciplined  programming  environment  now  has  to  be  made  more  directly  available  to  the 
user,  so  the  user  will  have  direct  access  and  control  over  the  system  programming  teams.  The  programming 
environment  consists  of  procedures,  handbooks,  and  a computer  which  contains  all  the  new  software  develop- 
ment tools  accessible  by  these  programming  teams.  The  environment  can  be  provided  to  the  user  by  transi- 
tioning to  the  operational  user  the  original  software  development  support  system  so  that  it  can  be  avail- 
able for  system  maintenance  and  modification. 
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The  one  phase  of  this  programming  process  that  Is  not  yet  satisfactory  is  the  front  end  or  require- 
ments definition  phase  where  the  user  attempts  to  define  his  needs  and  communicate  it  to  the  programming 
staff,  which  then  translates  it  into  a software  design.  There  are  Requirements  and  Design  Specification 
languages  under  development  that  do  two  things;  (1)  they  provide  a rigorous  and  standard  way  of  describing 
the  requirement  and  the  system  design,  and  (2)  they  provide  an  automated  way  to  analyze  both  the  require- 
ment and  the  design  for  Inconsistencies  and  deficiencies.  Other  approaches  Include  better  and  faster 
means  for  simulating  a proposed  system  modification  for  inspection  by  the  user.  A third  approach,  called 
automatic  programming,  is  an  attempt  to  go  directly  from  the  requirement  as  described  in  a special  language 
to  computer  code  with  no  intermediate  design  and  programming  phases.  This  latter  area  has  been  worked  to 
some  extent  and  experimental  systems  capable  of  automatically  generating  rather  simple  programs  have  been 
constructed.  Work  is  directed  at  more  efficient  program  synthesis  by  introducing  both  backtrack  proof 
searches  and  Interactive  user  intervention  in  the  search  process.  Other  work  attempts  to  replace  the  com- 
plete resolution  principle  proof  procedure  with  a more  direct,  though  incomplete,  Markov  algorithm  which 
has  the  additional  goal  of  optimizing  the  resultant  program  on  the  basis  of  rules  which  contain  knowledge 
of  both  programming  structures  and  the  domains  of  discourse  (numbers,  lists,  etc.). 

A second  and  more  ambitious  and  flexible  approach  to  system  requirement  and  design  is  that  of  problem 
definition  through  general,  interrogative-declarative  man-machine  discourse.  It  is  the  goal  of  some 
researchers  to  conduct  such  discourse  in  English.  One  of  the  most  advanced  discourse-based  projects  is  at 
Stanford  University.  Independent  advances  in  the  mechanical  processing  of  natural  language  have  resulted 
from  DARPA-sponsored  research  in  robots  and  speech  understanding.  One  of  the  most  total  approaches  to 
this  question  was  the  automatic  programming  project  at  the  MIT  Computer  Science  Laboratory  whose  goal  was 
to  pass  automatically  from  natural  language  discourse  to  a customized  inventory  control  system.  Work  at 
Harvard  is  directed  toward  semiautomatic  support  in  the  esperimental  optimization  of  programs,  including 
automatic  (though,  perhaps,  user  initiated)  data  restructuring. 

Other  approaches  are  problem  statement  via  example,  e.g..  System  for  Business  Automation  (SBA),  and 
problem  statement  by  sample  problem,  e.g..  University  of  Texas.  SBA  is  basically  an  applications  oriented 
programming  system  while  the  latter  work  is  based  on  the  automatic  generation  of  programs  by  a theorem 
prover. 

A current  project  under  development  at  the  Information  Sciences  Institute  of  the  University  of  South- 
ern California  is  the  SAFE  (Specifications  Acquisition  From  Experts)  system.  The  goal  is  to  produce  pro- 
grams from  semiformal  specification,  expressed  in  English,  similar  to  those  found  in  military  acquisitions 
contracts.  All  of  these  approaches  require  further  development. 

With  the  complete  implementation  of  software  engineering  technology,  we  would  be  in  a position  to 
modify  the  software  systems  on  a timely  basis  in  direct  reaction  to  the  user's  needs.  This  means  that  we 
at  least  would  have  the  flexibility  and  adaptability  for  the  more  routine  and  definable  automated  systems. 
At  the  same  time  Software  Engineering  applied  to  (r  implies  that  the  user/operator  of  the  Command  Center 
must  treat  his  software  the  same  way  he  manages  his  SOPs  and  Office  Instructions.  The  software  is  his  to 
help  his  organization  do  its  job,  it  must  be  customized,  documented,  controlled,  modified  and  most  of  all 
formalized  in  the  way  it  is  planned,  implemented  and  used;  Software  Engineering  does  this  for  him. 


COGNITIVE  AIDS  AND  KNOWLEDGE  BASED  SYSTEMS 

I would  like  to  address  the  man-machine  interaction  area  and  associated  cognitive  aids.  You  have  all 
heard  of  natural  language  query  systems  and  the  singular  lack  of  success  in  achieving  such  a capability. 

In  spite  of  this,  the  basic  need  is  still  to  provide  a communication  vehicle  which  allows  the  human  to 
phrase  a question  or  pose  a situation  in  his  own  natural  language  that  provides  the  richness  of  such  a 
language  and  requires  little  training.  This  language  must  be  translatable  to  computer  commands.  Of  course 
the  richness  of  the  natural  language  violates  the  rule  of  unambiguous  input  to  a computer.  The  approach 
to  this  dilemma  is  to  constrain  the  natural  language,  and  to  allow  easy  interaction  with  the  computer  so 
the  erroneous  computer  response  can  be  quickly  viewed  by  the  human  and  his  request  modified. 

This  is  the  way  human-to-human  communication  occurs  and  I see  no  fault  with  this  approach.  Continual 
lexographic  research  and  experience  with  various  query  languages  is  going  to  make  it  possible  to  obtain 
what  we  want.  But  what  we  want  and  what  the  various  staff  officer  levels  and  commanders  want  is  going  to 
be  different  until  we  observe  closely  the  problems  these  users  meet,  and  until  we  introduce  the  proper 
training  and  conditioning  of  these  people.  A whole  new  generation  of  people  used  to  working  at  computer 
terminals,  coupled  with  a better  understanding  of  and  visibility  into  the  computer  software  system  is 
going  to  relieve  this.  Of  course  research  in  voice  input  to  computers  will  also  help  the  problem  defini- 
tion phase. 

The  people  who  build  query  languages,  front  end  processing  languages,  terminal  oriented  decision 
aids,  etc.,  have  got  to  observe  closely  in  detail  the  problems  users  are  having  as  they  sit  at  the  comput- 
er terminals.  Except  for  routine  functions  as  in  reservation  systems,  banking,  etc.,  little  attention  has 
been  given  to  the  human  factors  aspects--1t  isn't  a research  problem,  it  requires  some  good  thinking  and 
persistent  hard  work. 

Given  that  we  achieve  satisfactory  human-to-machine  communication,  what  is  being  done  about  making 
the  computer  a more  useful  tool  for  the  knowledge  worker,  the  decision  maker,  the  cognitive  worker,  or 
whatever  you  want  to  call  that  person  who  has  to  perform  ill-defined  military  management  and  decision 
functions?  First  we  can  certainly  give  him  all  the  latest  technology  that  is  available,  including  word 
processing,  text  editors,  and  text  scanners,  relational  data  management  systems,  personal  file  systems, 
electronic  mail,  computer  conferencing,  dynamic  data  base  restructuring  and  on-line  operations  research 
tools.  The  challenge  here  is  the  engineering  and  tailoring  of  these  aids  for  the  specific  applications. 
Again,  here,  the  user  requires  control  over  and  direct  access  to  the  programing  development  process  and 
environment. 


The  RiD  community  Is  doing  something  with  these  standard  tools  to  help  this  class  of  user.  I quote 
from  a recent  Air  Force  Planning  Guide  which  presented  this  well: 

"Some  of  the  activities  at  various  Artificial  Intelligence  research  centers  are  applicable  to  the 
needs  for  more  knowledge  based  computer  tools  to  aid  in  decision  making  in  a C3  environment.  These  activ- 
ities can  be  divided  into  four  areas:  Problem  Solving,  Information  Integration,  English  Language  Inter- 
action, and  Reasoning  Explanation. 

"Problem  Solving.  For  a decision  aid,  the  "problem"  to  be  solved  is  to  formulate  options,  i.e., 
sequences  of  actions,  which  satisfy  the  goals  of  the  decision-maker  in  the  current  environment.  Early  AI 
work,  especially  that  developed  for  game  playing,  viewed  the  problem  solving  process  as  a heuristic  di- 
rected search  using  local  information  or  knowledge  to  arrive  at  a solution  through  a vast  solution  space. 
Newer  work  emphasizes  the  view  of  problem  solving  as  a "planning"  process.  In  this  process,  the  machine 
applies  overall  knowledge  of  the  problem  to  plan  a solution  by  defining  a series  of  subgoals  and  then 
applies  local  knowledge  to  reduce  the  subgoals  into  a sequence  of  actions  resulting  in  a solution. 

"Work  on  the  NOAH  system  at  Stanford  Research  Institute  uses  the  idea  of  hlerarchlal  refinement.  A 
plan  is  represented  by  a tree  in  which  each  descending  level  represents  more  detailed  refinements  of  the 
subgoals.  The  subgoals  in  the  plan  are  kept  unordered  until  the  interaction  between  each  subgoal  process 
is  defined  such  that  the  sequence  of  subgoal  accomplishments  can  be  determined. 

“Work  on  the  PLASMA  system  at  MIT  uses  the  notion  of  an  "island"  to  guide  the  planning  process.  An 
island  is  a step  in  the  solution  which  the  system  knows  must  be  present,  thus  greatly  reducing  the  number 
of  alternative  solutions  which  would  have  to  be  considered.  Other  work  at  MIT  uses  an  automatic  program- 
mer to  debug  the  effects  Introduced  by  the  interaction  between  Independent  subgoal  solutions. 

"All  of  the  planning  approaches  to  problem  solving  emphasize  the  use  of  knowledge  about  the  problem 
to  reduce  the  amount  of  search  to  arrive  at  a solution. 

“Information  Integration.  Techniques  for  integrating  diverse  sources  and  levels  of  information  have 
been  developed  as  a result  of  ARPA  funded  work  on  continuous  speech  understanding.  In  order  to  understand 
an  utterance,  the  speech  system  must  Integrate  higher  levels  of  information  on  pragmatics,  semantics, 
syntax,  and  phonetics  with  the  lower  levels  of  information  present  in  acoustic  signal  data. 

"Work  at  Carnegie  Mellon  University  is  based  on  an  elaboration  of  so-called  production  systems.  The 
Carnegie  Mellon  University  system  consists  of  several  Independent  knowledge  sources  containing  rules  which 
communicate  through  a cornnon  data  structure  called  the  "blackboard".  Using  situation-action  rules,  the 
current  subgoals  to  be  addressed  are  stored  symbolically  on  the  "blackboard"  and  any  "knowledge"  may 
execute  a process  and/or  update  the  "blackboard."  This  type  of  control  structure  also  allows  for  Identi- 
fying the  knowledge  source  with  the  best  capability  to  address  a particular  subgoal  of  the  system. 

"Current  work  on  complex  data  structures  for  representing  and  relating  information  is  being  done  at 
XEROX  Palo  Alto  Research  Center  and  MIT.  These  data  structures,  called  "frames,"  can  be  used  to  represent 
stereotyped  objectives  or  events,  making  explicit  the  components  and  interaction  between  various  elements. 

"English  Language  Interaction.  Graphical  displays  are  currently  used  to  present  and  sumnarize  Infor- 
mat 1 onrnweveFTutfii^TtSPIs- to  communicate  decision  options  as  opposed  to  information,  techniques 
are  needed  to  coirmunicate  at  a higher  level.  Recent  advances  in  natural  language  understanding  offer  the 
possibility  of  comnuni cation  in  English. 

"The  advantage  of  using  natural  language  is  based  on  the  system's  ability  to  understand,  e.g.,  that 
'How  many  F-4s  are  available?'  has  the  same  meaning  as  'Print  the  resource  field  of  the  aircraft  record 
which  has  the  name  field  equal  to  F-4.' 

"Much  of  the  current  work  In  natural  language  comnunlcation  is  focused  on  understanding  sentences  in 
context.  Efforts  at  Yale,  and  at  the  University  of  Maryland  are  focused  at  understanding  utterances  above 
the  level  of  a single  sentence.  Recent  attempts  have  been  made  to  apply  the  RAX  sponsored  Rapidly  Exten- 
sible Language  (REL)  development  at  Cal  Tech  to  the  problems  of  using  English  for  data  base  retrieval. 

"The  University  of  Illinois  Is  taking  an  engineering  approach  to  language  understanding  by  using  a 
large  number  of  "request  templates"  and  pattern  matching  Instead  of  a traditional  parsing  system.  This 
system  is  especially  interesting  since  It  addresses  the  domain  of  data  base  retrieval  of  aircraft  mainte- 
nance and  flight  information. 

"Stanford  Research  Institute  is  currently  building  a natural  language  data  base  retrieval  system  for 
Navy  Advanced  Command  and  Control  Architecture  Testbed  (ACC AT) . The  work  at  SRI  uses  an  already  existing 
data  base  management  system,  (The  OATACOMPUTER)  and  attempts  to  translate  English  requests  into  the  re- 
trieval language  of  the  underlaying  data  base  system. 

“Reasoning  Explanation.  In  the  C3  environment,  man  is  still  the  ultimate  decision  maker.  Any  useful 
system  must  be  able  to  explain  and  justify  its  options  in  terms  understood  by  the  user  of  the  system. 

A similar  problem  has  been  faced  by  Al  researchers  trying  to  produce  automated  aids  for  medical  diagnosis. 
Since  the  physician  is  ultimately  responsible  for  the  patient,  any  useful  diagnostic  aid  must  not  only 
present  him  with  options  but  allow  him  to  scrutinize  and  examine  the  method  used  by  the  system.  The  most 
advanced  work  has  been  done  by  the  MYCIN  group  at  Stanford  University.  The  MYCIN  system  is  able  to 
explain  the  reasoning  chain  used  in  reaching  a diagnosis.  This  explanatory  ability  is  useful  in  four  ways 

"(1)  As  an  educational  tool,  it  helps  novice  users  by  demonstrating  accepted  methodology. 

"(2)  As  a justifying  source,  it  helps  to  assure  that  the  diagnosis  and  treatment  is  correct. 

*(3)  As  a debugging  aid,  it  helps  the  expert  user  pinpoint  where  the  system  made  an  error. 
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"(4)  As  a knowledge  screening  source.  It  shows  the  physician  Information  relevant  to  the  case  In 
question." 

In  spite  of  all  this  R&O  one  must  recognize  that  experience  at  the  terminal  by  the  military  user  Is 
the  best  way  to  obtain  the  visibility  Into  the  system  and  to  devise  his  own  problem  solving  techniques. 


4 

DISTRIBUTED  DATA  PROCESSING. 

Given  a high  degree  of  automation,  Distributed  Data  Processing  Is  the  technology  needed  to  link  all  of 
this  together  Into  a cohesive  system.  Distributed  Data  Processing  - What  Is  It?  It  Is  a group  (2  or  more) 
of  computer  processors  (or  computer  systems)  coupled  together  to  carry  out  a set  of  processes  (functions) 
where  a high  degree  of  dependency  among  either  the  processors  or  the  functions  Is  required.  The  scope  can 
range  from  two  microprocessors  sharing  a limited  process  control  function  to  a global  linking  of  many  large 
diverse  computer  systems  sharing  data  and  functions  In  a military  or  Industrial  command  management  system. 

The  requirements,  technical  challenges,  as  well  as  the  technical  approaches  vary  widely  over  this  broad 
range.  The  technical  challenge  In  having  two  identical  microprocessors  share  the  results  of  two  separate 
processes  one  running  on  each  device  Is  of  an  entirely  different  magnitude  than  the  challenge  posed  by  the 
Interoperability  among  multinational  conmand  systems  using  different  computer  hardware  and  operating  systems. 

Distributed  Systems  differ  In  many  ways: 

The  degree  of  coupling  and  dependency  among  the  elements  of  a distributed  system  can  vary  greatly;  some 
systems  pose  unusual  requirements  on  the  communication  scheme  used,  others  none  at  all;  the  number  of  separ- 
ate units,  even  though  simple  In  nature,  that  make  up  a distributed  system,  can  pose  major  challenges  if 
the  number  Is  very  large;  some  systems  operate  In  a completely  decentralized  mode,  others  with  tight  central 
control;  some  systems  are  highly  redundant  while  others  impose  stringent  reliability  demands. 

The  Distributed  System  of  Interest  In  this  paper  Is  the  one  that  links  together  the  data  processing 
elements  that  make  up  Surveillance,  Intelligence,  Conmand  and  Control.  These  are  characterized  by  a re- 
spectable number  of  medium  to  large  scale  computers  with  a fairly  large  number  of  minicomputers  and  micro- 
processors as  satellite  processors,  primarily  for  data  Input.  All  of  these  are  separated  geographically, 
utilize  a variety  of  conmunlcatlons,  perform  independent  and  diverse  functions  and  most  Importantly  are 
computers  from  a variety  of  manufacturers  and  which  utilize  a variety  of  Operating  Systems,  many  of  which 
are  tailor-made  for  the  specific  application. 

There  are  several  purposes  for  a Distributed  System  In  this  environment,  the  primary  one  being  the  need 
to  transfer  and  access  data.  A secondary  purpose  is  to  Increase  the  survivability  of  CZI  through  backup 
and  redundancy,  and  a third  purpose  Is  to  allow  the  sharing  of  computer  power  during  overload  periods. 

There  are  several  levels  of  Interaction  or  Interoperability  that  might  be  required  for  the  above  pur- 
poses. The  ultimate  capability  required,  and  the  highest  level  of  Interaction,  Is  the  ability  to  transfer 
Individual  records  of  data  among  the  machines  along  with  the  software  modules  that  functionally  operate  on 
these  Individual  records,  all  done  In  such  a way  that  it  would  appear  as  if  the  Distributed  System  was  one 
functional  multi -programmed/multi -processor  computer  system.  Such  a capability  is  not  technically  feasible 
today,  although  there  are  Instances  of  multi -program/multi -processor  computers  where  the  hardware  is  identi- 
cal and  a single  operating  system  Is  used.  Even  here  much  remains  to  be  done  to  improve  the  reliability 
and  performance  of  such  a computer.  A much  lower  level  of  interactive  capability  and  which  I will  call  the 
second  level  Is  the  ability  to  transfer  whole  files  from  one  machine  to  another  of  different  manufacture, 
so  that  the  data  can  be  operated  on  by  the  software  process  In  the  computer  to  which  the  data  is  transferred. 

This  capability  has  been  implemented  on  a case  by  case  basis;  recently  a more  universal  solution  to  this 
file  transfer  requirement  has  been  demonstrated  through  a DOD  program  called  the  National  Software  Works 
(NSW).  There  are  several  levels  of  Interaction  between  the  extremes  and  one  must  be  careful  to  specify 
the  level  when  describing  a requirement  or  a capability  in  Distributed  Systems. 

The  NSW  Program  has  demonstrated  the  ability  of  a user  at  any  terminal  to  request  access  to  any  host 
computer  In  the  Distributed  System  and  to  utilize  the  software  on  that  host  for  whatever  purpose  desired 
and  to  transfer  the  results  of  a process  on  one  host  to  a file  in  a second  host  and  then  to  initiate  a pro- 
cess In  the  second  host  to  operate  on  this  file.  All  this  would  be  done  without  having  to  learn  the  pro- 
tocols, the  job  control  language,  and  the  file  structure  of  any  of  the  computers.  The  user  interacts  with 
the  total  system  through  a common  language  and  all  file  transfers  between  machines  are  converted  automatic- 
ally for  operation  in  the  second  machine.  A network  operating  system  called  a Works  Manager  is  used  to 
control  the  assignment  of  host  computers  and  their  resources  to  a user,  takes  care  of  all  accounting  situ- 
ations, and  accomplishes  all  file  conversions. 


A Front  End  Processing  System  provides  a universal  transfer  Interface  both  between  the  user's  terminal 
and  the  ARPANET  and  between  the  user  and  any  host  machines  by  providing  a conmon  protocol  and  job  control 
language,  and  other  functions.  Software  In  the  host  machine  called  the  Forman  links  the  local  operating 
system  and  the  services  of  the  host  machine  to  the  NSW  System,  without  Interfering  with  the  functions  of 
the  local  host  operating  system.  Initially  this  capability  allows  a fairly  low  level  of  Interaction 
mentioned  above,  namely  the  transfer  of  whole  data  files  among  different  computer  systems;  access  to  those 
data  files  and  their  transfer  Is  made  easy  and  on  a real  time  basis  even  for  the  first  time  case.  There  is 
as  yet  no  capability  to  transfer  software  processes  nor  to  access  files  at  the  record  level.  All  of  the 
above  functions  are  controlled  by  the  network  operating  system  called  a Works  Manager;  this  may  run  on  one 
or  more  of  the  host  machines  and  operates  in  a noninterference  mode  with  the  local  operating  systems.  The 
Front  End  processing  can  be  accomplished  either  on  a PDP  11/40  or  In  the  host  machine  Itself.  The  system 
Is  designed  to  be  Independent  of  the  communications  media  and  can  be  transferred  from  the  ARPANET  to  AUTO- 
DIN II  or  other  communications  with  a minimum  amount  of  software  development.  This  system  is  intended  to 
be  a universal  design  approach  to  the  networking  of  dissimilar  computer  systems  where  at  least  a second 
level  of  Interaction  Is  required. 


Other  research  and  development  Is  being  performed  on  network  operating  systems  and  distributed  data 
base  systems  which  will  allow  a higher  degree  of  Interoperability.  At  this  time  development  of  such  a 
capability  appears  to  be  of  medium  risk  and  It  Is  expected  that  within  10  years  a very  high  level  of  Inter- 
action or  Interoperability  In  a Distributed  System  will  be  operationally  possible. 

It  should  be  pointed  out  that  the  technical  ability  In  a computer  science  sense  to  achieve  this  high 
level  Interoperability  requires  a comnensurate  management  capability  and  system  architecture  capability  to 
take  advantage  of  such  technology.  This  must  also  be  coupled  with  the  ability  to  accomplish  performance 
evaluation  of  various  architectures  In  a Cm  environment,  so  as  to  Insure  that  the  Distributed  System 
Architecture  can  meet  the  operational  requirements  In  a practical  manner.  This  In  fact  Is  the  most  chal- 
lenging R&D  yet  to  be  performed;  namely,  System  Architecture  Design  and  Evaluation.  Equally  important  Is 
the  ability  to  analyze  the  operational  requirements  In  terms  of  data  flow  and  processing  function  assign- 
ments, coupled  with  the  system  reliability  requirements. 

During  the  next  20  years  such  distributed  systems  will  extend  themselves  to  the  lowest  unit  level  be- 
cause of  the  advent  of  very  large  scale  Integration  (VLSI).  This  has  already  manifested  itself  In  terms  of 
microprocessors  which  can  be  very  Inexpensive  and  provide  local  processing  capability  for  interacting  with 
a Distributed  System.  The  advent  of  Inexpensive  computer  hardware  poses  tremendous  system  architecture 
design  problems,  but  holds  out  the  hope  of  possibly  substituting  inexpensive  hardware  for  some  expensive 
software.  By  this  I do  not  mean  that  the  microprocessor  will  replace  the  software,  although  it  will  per- 
form a software  function;  Instead  much  of  the  supervisory  or  overhead  software  for  time  sharing  systems 
may  not  be  required  In  the  era  of  cheap  computer  systems.  Such  highly  decentralized  processing  may  reduce 
the  extent  of  functions  handled  by  today's  operating  system  software  which  Is  required  today  to  make  more 
efficient  use  of  the  fairly  expensive  large  computer  hardware.  Of  course  redundancy  and  survivability 
requirements  are  also  somewhat  alleviated  by  Inexpensive  decentralized  processing  capability. 

The  nature  of  command  and  control  and  intelligence  Is  such  that  a range  of  computer  systems  from  the 
personal  microprocessor  to  the  large  scale  data  base  machines  are  going  to  be  required  In  the  foreseeable 
future.  This,  together  with  the  fact  that  standard  military  computer  architectures,  such  as  standard 
Instruction  sets.  If  Implemented  at  all  will  not  Impact  on  the  military  computer  environment  for  CM  for  a 
good  number  of  years  means  that  the  capability  to  handle  distributed  processing  on  several  size  machines 
of  different  manufacture  in  a tactical  environment  Is  a prime  c2l  requirement. 

Distributed  Processing  Systems  In  the  ultimate  sease  of  extreme  Interaction  coupled  with  the  very  In- 
expensive digital  hardware  opens  up  opportunities  and  challenges  that  today  stretch  the  Imagination  even 
more  than  the  advent  of  time  sharing  did  In  1965.  We  have  gained  a lot  of  practical  experience  In  apply- 
ing time  sharing  which  I think  Is  going  to  allow  the  military  to  do  a much  better  job  of  taking  advantage 
of  this  advancing  computer  technology  with  all  Its  potential  and  limitations  - I sincerely  hope  so. 
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DISCUSSION 


Question : 

Would  the  speaker  say  a little  bit  more  about  automated  programming. 

Author’s  Reply 

(a)  The  term  “automatic  programming”  as  it  relates  to  the  problems  of  command  control  presents  an  initial 
dichotomy  depending  on  the  immediate  goals  of  the  user.  On  one  hand  we  have  those  efforts  aimed  at 
reducing  the  time  and  cost  of  software  production  by  automating  part  or  all  of  the  production  process.  On  the 
other  hand  we  have  efforts  directed  toward  producing  systems  capable  of  accessing  distributed  data  bases  and 
directly  synthesizing  the  knowledge  retrieved  in  response  to  a natural  language  query  or  command.  No  soft- 
ware for  external  use  is  provided  in  this  case:  the  goal  of  the  system  is  to  produce  real-time  answers. 

(b)  Careful  scrutiny  of  the  methods  of  software  production  yields  three  basic  processe  T at  a system  may  utilize 
to  obtain  the  required  program : (It  The  system  can  take  a high  level  language  program  or  a program  descrip- 
tion in  a suitable  formal  specification  language  and  directly  convert  this  to  the  target  program.  (2)  Using 
formal  input-output  specifications  the  system  can  attempt  an  exhaustive  enumeration  of  the  set  of  all  proofs 
until  an  acceptable  answer  is  found.  (3)  The  system  may  be  able  to  build  an  acceptable  program  by  modifying 
and/or  combining  known  (and  suitable  documented)  programs  that  reside  in  a programming  data  base.  Short 
term  payoffs  for  narrowly  defined  applications  domains  in  command  and  control  are  envisioned  here. 

(c)  The  other  view  of  automatic  programming  has  led  recently  to  running  systems  with  impressive  capabilities. 

The  LADDER  system  of  E.Sacerdoti  at  SRI  responds  to  natural  language  queries  and  commands.  Working  with 
a large  naval  data  base,  it  performs  a complicated  synthesis  of  the  results  of  its  data  search  in  arriving  at  the 
answer.  PROSPECTOR,  also  of  SRI  under  P.Hart,  is  a rule-based  system  that  serves  as  an  expert  diagnostician 
for  the  field  geologist  in  his  search  for  ore.  In  duplicating  the  responses  of  experts  in  the  field  in  question, 
such  systems  are  currently  operating  at  levels  beyond  the  average  practitioner. 


Question : 

In  your  printed  paper  you  have  stated  that  no  one  understands  the  decision  process  associated  with  command  and 
control.  It  seems  to  me  that  this  is  for  the  moment  a stumbling  block  in  the  extensive  use  of  computers  in  the  C2 
process?  I am  just  wondering  if  even  with  a window  into  the  automated  C&C  process  it  will  be  possible  to  overcome 
this  diffculty?  What  do  you  mean  by  window? 

Author’s  Reply 

(a)  The  decision  process  in  command  and  control  cannot  be  defined  or  described  so  that  one  can  program  a 
computer  to  either  perform  the  process  or  to  explicitly  provide  the  proper  information  to  the  human  decision 
maker  by  means  of  an  a priori  computer  program.  This  is  because  the  human  is  reacting  to  an  unanticipated 
situation  which  involves  different  information  and  different  criteria  for  a decision.  Yet  there  are  quite  a few 
anticipated  situations  that  are  handled  by  computer  programs  that  retrieve  previously  specificed  information, 
process  it  and  display  it  as  specified. 

(b)  If  the  staff  officer  in  a C2  Center  understands  why  a particular  program  was  written,  the  nature  of  the  data 
base  it  operates  on,  and  the  processes  it  performs,  then  this  program  might  be  able  to  be  used  to  obtain  and 
display  the  information  needed  for  this  new  situation.  The  staff  officer  will  have  to  make  some  intelligent 
changes  in  the  way  he  uses  this  program  and  interprets  the  displayed  data.  He  can  do  this  only  if  he  can  appre- 
ciate how  the  computer  system  is  handling  his  request. 

(c)  The  window  I am  referring  to  is  the  capability  of  the  C2  staff  officer  to  modify  or  tailor  the  existing  computer 
programs  and  procedures  so  that  he  can  continue  to  carry  out  his  decision  process.  We  still  don’t  understand 
the  decision  process  used  by  the  staff  officer  when  he  encounters  a new  situation,  but  we  give  him  the  flexi- 
bility and  tools  to  allow  him  to  use  and  adapt  the  computer  system  for  his  purposes. 


SOFTWARE  FOR  ROYAL  NETHERLANDS  NAVY 


Johan  B.F.  Tasohe, 

Centre  for  Automation  of  Weapon 
and  Command  Systems  (CAWCS), 
Royal  Netherlands  Navy  (RNLN), 
Nieuwe  Haven, 

Den  Helder,  the  Netherlands. 
SUMMARY 


This  paper  deals  with  the  experience  gained  by  the  in-house  development  of 
real-time  software  for  large  shipborne  command  and  control  systems  for  the  Royal 
Netherlands  Navy.  The  intention  is  to  demonstrate  the  RNLN ' s "both  feet-on-the-deck 
approach"  to  the  problem  of  finding  a path  through  the  software  engineering  jungle 
followed  by  the  RNLN.  To  simplify  things  and  try  to  find  out  real  trends  is  especially 
important  in  software  engineering,  for  there  seems  to  be  more  inventiveness  in 
introducing  new  words  and  phrases  than  real  new  ideas.  It  is  the  authors  opinion  that 
software  engineering  itself  progressed  only  slowly  over  the  past  10  years,  but  since  the 
famous  Garmisch  (1968,  (3))  and  Rome  (1969,  (**))  conferences  there  is  an  exponentially 
increasing  interest  in  software  engineering  and  related  problems.  Well  defined  and 
solvable  problems  have  been  over-treated,  but  a few,  from  the  user/software-producer 
point  of  view  more  important  but  ill-defined  and  perhaps  unsolvable  problems,  have 
received  little  attention.  Software  engineering  for  command  and  control  systems  is  a 
part  most  times  the  major  part,  of  the  total  project's  system  engineering.  This  is 
especially  true  in  the  RNLN. 

1 . INTRODUCTION 


Over  the  years,  an  overwhelming  amount  of  paper,  books  etc.  on  problems  in 
software  is  published.  This  clearly  demonstrates  that  software  although  it  is  no  longer 
"the  art  of  programming",  is  still  no  "industrial  product"  with  established  quality 
standards  and  production  quantities.  The  enormous  sums  of  money  spent  on  software  and 
the  increasing  importantance  of  software,  requires  a continuous  effort  from  the  producers 
to  obtain  optimum  software  production  techniques.  Indeed  the  interest  in  software 
engineering  matters  is  increasing,  the  amount  of  papers  produced  is  increasing  even 
faster  and  software  engineering  has  become  a jungle  from  which  is  difficult  to  get  out. 

No  solutions  have  yet  been  found  for  overcomming  the  high  cost  of  software,  but  what 
is  more:  there  is  not  even  a real  indication  of  a breakthrough.  The  CAWCS  has  been  in 
this  jungle  from  its  inception  in  1968,  and  has  been  confronted  with  all  the  difficulties 
in  this  ill-defined  area.  We  have  not  attempted  to  find  special  case  solutions  to 
problems,  but  have  always  tried  to  see  things  simply  as  possible.  By  doing  so  we  have 
been  able  to  specify,  design,  produce  and  test  software  for  large  command  and  control 
systems  in-time,  in-budget  and  with  the  required  performance. 

In  para  2 an  oversimplified  review  of  major  software-engineering  trends  is  given.  The 
point  of  view,  it  has  to  be  explicitely  stated,  is  CAWCS,  thus  the  very  practical 
producer/software-engineering  point  of  view.  Two  recent  publications  (18,  34 ) are 
offering  excellent  starts  for  tutorial  and/or  further  detailed  reading. 

In  para  3 the  practical  case  of  the  CAWCS  is  considered  as  a typical  example.  Only  a 
few  characteristic  points  will  be  highlighted.  It  is  believed  that  every  programming 
centre,  or  programming  project  group  etc.  has  typical  characteristics,  thus  experiences 
cannot  simply  be  transferred. 
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In  para  4 two  typical  problem  areas  will  be  discussed,  which  are  to  the  authors  knowledge 
not  yet  sufficiently  solved,  but  form  the  achilles-heel  of  the  big  software  projects  of 
the  near  future. 

2.  SOFTWARE  ENGINEERING  TRENDS 


2.1.  Headlines  of  the  past. 

"In  the  beginning  was  SAGE" 

J.  Leth-Espensen.  (1). 

"Programs  do  not  acquire  bugs  as  people  do  germs 
-just  by  hanging  around  other  buggy  programs. 

They  acquire  bugs  only  by  having  programmers 

insert  them". 

Harlan  D.  Mills. 

After  the  famous  Von  Neumann  invention  to  not  only  store  data  and  variables  but 
also  programs  ("stored  program  digital  computers"),  the  program  flow  inherently  got  a 
flexibility  unknown  until  that  time.  The  programming  job  was  born,  software  became  a word 
and  the  devil  became  a new  face:  bugs. 

In  the  late  '50's  the  first  attemp  to  increase  programming  speed  and  limit  the 
number  of  bugs  was  to  let  the  new  machines  do  their  own  administration:  assemblers  and 
higher  order  languages  were  born.  Capability,  compatibility,  transportability  etc.  became 
main  topics  and  assemblers/languages  became  a high  technology  engineering  (1)  (3),  (4). 
Assemblers/language  are  of  tremendous  technical/commercial  importance  and  have  over  the 
years  proved  to  be  very  adaptive  in  following  the  programmers  needs.  Assembler/languages 
made  the  opening  into  wide-spread  use  of  computerbased  systems  and  there  is  still  a 
remarkable  evolution  (10),  (11). 

In  the  early  '60's  it  became  clear  that  for  large  programs  the  design  was  more 
the  weak  part  than  coding  itself.  This  led  to  program  and  data  segments,  later  modules, 
controlled  by  executives/schedulers  and  organised  around  a compool  (2).  Techniques  now 
known  as:  top-down,  documentation  tree,  stepwise  refinement,  structured: 
coding-programming-design-walkthrough -approach,  nodular  decomposition,  matrix- 
organisation,  chief  programmer  team  etc.  have  been  explored  and  shown  to  be  effective 
by  those  responsible  for  the  early  big  and  difficult  projects.  Everybody  was  smiling  and 
proud  to  be  working  in  difficult  projects,  but  was  not  telling  his  neighbours  about  his 
principal  problems! 

In  the  end  '60's  however  the  problems  started  to  be  discussed  in  broader 
spectrum,  mainly  due  to  the  two  trendsetting  conferences  on  software-engineering.  The 
conference  proceeding  material  (3)  (4)  is  nearly  unchanged  valid  today  and  is  still  a 
MUST-reading  for  every  software  engineer!  At  the  same  time  the  buyers,  e.g.  US  DoD, 
started  to  tackle  the  problems  of  high  cost,  late  delivery,  unreliability  and  undue 
complexity  of  the  software  from  their  side  by  requiring  adequate  procurement  and  control 
documentation  (31)  (32).  The  famous  WS8506  specification  ("documentation  tree")  soon 
became  known  as  a very  helpful  guide  for  software  managers  to  set  up  and  control  their 
own  projects,  being  complementary  to  the  other  software  techniques  (special  to  top-down 
and  structured-). 


In  the  '70's  nothing  really  new  happened.  There  came  a lot  of  refinements  and 
a lot  of  new  words.  The  main  technology  is  still  based  on  straight  forward  common  sense 
thinking  (top-down,  structured-)  and  writing  (doc.  tree),  and  mankind  demonstrated  the 
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sucoes  in  hundreds  of  large  projects.  Some  new  aspects  are  covered  or  more  seriously 
treated:  e.g.  testing,  certification,  quality  control  (7)  (8)  (2*1)  intellectual  owner- 
ship (9)  and  the  known  techniques  are  being  applied  to  new  fields  (23).  Psychologists 
analyzed  the  man  behind  the  programmer  (27)  (28);  interesting,  perhaps  important,  but 
not  solving  any  engineering  problem.  The  most  important  however  is  the  much,  much,  much 
wider  understanding  of  the  existing  problems  and  the  related  interest  in  the  available 
techniques  (13)  (14)  (15)  (16)  (17)  (18)  (19)  (29)  (30)  (3*0  (35). 

2.2.  Headline  of  the  future. 

"I  would  add  as  a corollary  that  large  real-time  programs 
require  new  tools  in  oder  to  handle  the  production  task 
adequately" . 

James  H.  Burrows,  (2). 

Currently  software  engineering  is  widening  its  scope  but  there  is,  in  the 
authors  opinion,  no  trend  forward  a breakthrough. 

One  of  the  major  reasons  is  the  ever  increasing  speed  of  hardware  development 
in  which  in  a lineair  increasing  time-scale  the  packing  densities  and  processing  speed 
increases  exponential  while  prices  decrease  exponential.  This  will  not  end  before  the 
actual  physical  borders  are  reached.  This  is  estimated  to  be  somewhere  around  1985. 
Multi-computersystem,  microprocessorcontrolled  intelligent  peripherals,  distributed 
databases,  computernetworks , no-limit  memoryspace  etc.  etc.  will  keep  off  software/systems 
engineers  from  thinking  of  software-engineering  itself. 

One  trend  has  been  visible  already  for  years  and  will  be  increasingly  important: 
SYSTEM  ENGINEERING  becomes  SOFTWARE  ENGINEERING. 

More  and  more  specially  designed,  and  thus  expensive,  hardware  will  be  replaced  by  cheap 
but  powerful  processors.  A lot  of  hardware  engineering  effort  will  no  longer  be  necessary, 
thus  making  hardware  cheaper,  for  "this  will  be  done  by  software".  Variety  in  types  will 
become  exclusively  variety  in  software  to  keep  the  price  of  main-production  hardware  low. 
The  hardware-software  cost  ratio  for  a project  will  agressively  demand  cheaper  software. 
Where  is  the  new  software  technology? 

A second  trend  is  the  decreasing  influence  of  defense  systems  projects  in 
dataprocessing  development.  In  the  hardware  field,  the  defense  systems  are  already 
starting  to  follow  the  commercial  industry  (12)  and  the  same  for  software  is  already 
visible  (11).  Costs  is  a good  reason  to  go  in  this  direction  for  the  time  being,  but  the 
high  inertia  of  industry  in  the  direction  of  cheap  mass-products  does  not  necessarily 
parallel  the  governments  need  for  a few  extremely  complex  systems.  Where  will  the  new 
software  technology  for  complex  defense  systems  come  from? 

3.  THE  CAWCS.  A CASE  STORY 

"Among  programmers,  there  is  a certain  mystique  - a certain 
waving  of  the  hands  which  takes  place  whenever  one  tries  to 
probe  the  manner  in  which  programming  is  done.  Programming  is 
not  done  in  a certain  way,  they  say,  it  is  just  done.  Either 
you  can  program  or  you  cannot.  Some  have  it;  some  don't". 


Gerald  M.  Weinberg  (28). 
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3.1.  Brief  survey,  task. 


The  CAWCS  started  its  operation  in  early  1967,  not  accidentally  in  the  same 
period  that  software  engineering  became  a discussion  subject.  The  minister  of  defense 
specified  the  task  of  the  CAWCS  as  (simplified): 

a.  (In  cooperation  with  the  MOD  procuring  agencies)  to  coordinate  projects  on 
command,  control  and  weapon  systems,  with  specific  concern  for  problem  analysis, 
determination  of  configuration,  setting  of  priorities  and  planning, 

b.  To  do  system  and  program  analysis  and  design  for  these  systems. 

c.  To  produce  and  test  software  for  these  systems. 

d.  To  produce  systems  level  documentation  for  these  systems  as  operational  instruction 
for  the  users. 

e.  To  maintain  the  software  for  these  systems. 

f.  To  be  the  specifying  and  controlling  agency  for  software  produced  by  third  parties. 

e.  To  do  a few  less  important  tasks. 

This  is  really  more  than  just  making  software! 

The  CAWCS  started  with  5 people  and  today  there  are  about  100;  little  future 
growth  is  envisaged.  The  CAWCS  started  with  one  120  manyear  job  and  is  currently  involved 
in  three  major  projects  of  roughly  70  manyears  each  in  directly  assigned  personnel.  The 
non-directly  involved  personnel,  e.g.  administration,  typist,  computeroperators/ 
maintainers,  general  management  etc.,  constitute  an  overhead  of  about  100$.  The  average 
projecttime  is  about  5 years. 


3.2.  Personnel. 

The  explosive  relative  growth  of  personnel  is  shown  in  figure  1. 

The  average  new  programmer  comes  in  at  about  age  20  with  no  experience  in 
dataprocessing  and  no  special  dataprocessing  education.  There  is  no  typical  background 
but  the  levels  vary  from  highschool  to  Msc  and  specialisation  from  nothing  to  mathematics, 
physics,  mechanical  engineering,  merchant  marine  officers  etc.  The  know-how  in  accumulated 
years  is  shown  in  figure  2.  Each  year  the  average  age  (now  30)  increases  by  about  0.8 
years.  About  50$  of  the  personnel  is  military,  the  rest  civil  service. 

A typical  problem  in  a growing  government  organisation  (at  least  in  the  Netherlands) 
is  the  difficulty  to  get  the  right  people  in  time. 

3.3.  Organisation. 

The  organisational  chart  is  shown  in  figure  3. 


Department  1 consists  of  10  naval  officers,  from  all  operational  disciplines. 
There  is  no  further  internal  organisation. 

Department  2 contains  the  directly  project  involved  people  (about  60).  The 
internal  organisation  is  havily  influenced  by  the  few  experienced  people  and  by  the  few 
big  projects.  It  is  mainly  a project  organisation,  but  there  are  some  matrix-aspects.  A 
typical  aspect  in  this  project  organisation  i3  the  test  and  integration  group.  It  is  a 
well  defined,  separate  group,  but  operating  under  responsibility  of  the  projectleader . 

The  internal  organisation  of  the  departments  3 and  <1  are  of  no  importance  for 
this  paper. 

Organisation,  and  how  to  tackle  a project  has  proven  to  be  an  evolutionary 
process,  and  is  a continual  point  of  discussion. 


Software  engineering 
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The  CAWCS  is  continuously  reviewing  and  with  an  open  mind  following  various 
software  engineering  "innovations",  but  discussions  are  mainly  very  pratical  oriented 
and  based  on  "boerenverstand"  (Dutch  version  of:  common  sense). 

The  CAWCS  has  find  a few  techniques  very  succesfull  and  thus  helpful  (figure  *(): 

* WS8506 . Thus  a documentation  tree.  CAWCS  internal  documentation  system  differs  only  a 
little  from  the  official  specification  as  the  CAWCS  is  its  own  procuring  agency! 

WS8506  has  shown  to  be  extremely  helpful  to  CAWCS,  especially  because  it  stresses 
structural  thinking  on  the  various  levels  of  documentation.  A documentation  tree  like 
WS8506  clearly  distinguishes  various  production  and  documentation  steps  and  clearly 
seperates  testing  from  program  specification,  design  and  coding.  It  not  only  enforces 
top-down  design  and  stepwise  refinement,  but  it  makes  visible  the  various  production 
steps.  It  proved  to  be  easy  to  learn  and  use.  (figure  5,  simplified  WS8506). 

Another  important  documentation  tool  is  STOP  (33). 

This  documentation  and  material  presentation  method  helped  much  in  firstly  making 
systems  level  documentation  for  the  operational  user  and  secondly  in  proper 
understanding  of  the  operational  features  by  this  user.  It  helped  to  introduce  the 
systems  smoothly. 

* JOVIAL  (J3).  Certainly  not  the  latest  language,  perhaps  not  the  best  on  this  moment. 
It  was  certainly  one  of  the  best  when  we  purchased/produced  the  compiler.  It  is  really 
a high-level-language  (HOL,  higher  order  language)  and  it  still  is  one  of  the  best.  But 
by  far  the  most  important  characteristics  are  that  the  language  over  the  years  proved 
to  be  good  enough  and  what  is  even  more  important:  it  is  our  standard  language. 

x Manmonth . or  more  generally:  manning. 

The  aspect  personnel  is  not  too  often  considered  an  aspect  of  software  engineering, 
but  at  CAWCS  a lot  of  time  is  spent  getting  the  right  person  to  the  right  place.  And 
that's  the  best,  for  a couple  of  reasons.  Generally  production  time  decreases  when  the 
number  of  assigned  personnel  increases,  (constant  number  of  manmonth).  When  there  are 
however  too  less  persons  the  project  runs  unmanagable  long,  when  there  are  too  many 
persons  the  project  becomes  unmanagable  complex.  We  found  the  optimum  between  10  and 
20  programmers . 

A related  problem  is  planning. 

CAWCS  finds  it  most  helpful  to  start  a project  slowly  with  just  a very  few  carefull 
selected  analysts/programmers  and  then  to  increase  the  number  of  assigned  people  as 
required;  preferably  not  more  than  20  people  directly  assigned  to  a project.  This 
policy  seems  to  delay  the  project  about  one  year,  but  will  save  a considerable  amount 
of  manyears.  In  fact  a short  planned  delay  is  introduced  at  the  very  start  of  a project 
to  assure  enough  sophistication  in  e.g.  system  specification  and  design  and  to  assure 
project  delivery  at  the  planned  time.  ("Why  seems  there  always  to  be  time  to  do  a job 
again  and  again,  but  never  time  to  do  it  properly  from  the  beginning?").  CAWCS  has 
never  been  late  in  delivering  software  incl.  documentation! 

A third  aspect  to  manning  is  the  package  of  total-know -how  available  in  one  centre. 

In  department  1 (figure  3)  all  and  the  latest  operational/tactical  know-how  is 
concentrated  and  ready  for  direct  consult,  discussion  and  confrontation.  In  department 
2 all  systems,  hardware  and  software  know-how  is  concentrated.  In  all  stages  of  the 
projects  and  an  all  levels  in  the  organisation  these  two  major  departments  work  strongly 
together. 

x System  engineering.  CAWCS  considers  it  very  helpful  to  have  a (shared)  position  in 
system  engineering  (task  a).  This  is  considered  to  be  the  single  most  important 
contribution  to  the  succes  of  software  making.  The  determination  of  the  configuration, 
the  setting  of  priorities  and  the  planning  can,  to  a certain  amount,  be  optimised  from 
the  software  point  of  view.  This  has  the  inherent  pro's  of:  lesser  system  engineering 
risks,  better  optimised  systems,  smoother  planning  etc.  Software-concious  hardware! 


As  the  CAWCS  plays  an  important  role  in  RNLN  system  engineering,  hardware  standadization 
could  be  effected.  This  eliminated  the  need  for  more  types  programming  centre  computers, 
languages  etc,  and  thus  greatly  eases  software  engineering  and  enhances  the  programming 
centre's  efficiency.  For  the  CAWCS  is  software  procuring  agency  and  mainfacturer  in  one 
hand,  it  is  possible  to  write  the  final  SW  specification  when  the  project  is  already 
started.  This  considerably  saves  time  and  gaines  quality.  This  time  can  be  consumed  in 
the  already  mentioned  low  profile  start.  Also  important  is  that  the  system  engineers 
are  in  direct  and  daily  contact  with  operational  users  (customers). 

3.5.  Some  results. 

In  figure  9 the  absolute  producution  speed  are  given  for  the  four  DAISY'S 
(digital  automated  information  processing  systems)  that  finished  their  production. 

It  concerns  direct  assigned  personnel,  and  includes  the  system  engineering  activities. 
The  CAWCS  does  not  consider  this  high  production  speed,  but  it  is  not  clear  how  to 
enhance  the  speed.  The  four  projects  were  all  delivered  on  time  and  within  budget. 

The  same  has  to  be  applicable  for  the  current  projects.  When  not  only  the  new  code, 
but  all  the  produced  code  is  accounted  for,  the  asterix'  and  dotted  line  applies. 

Figure  10,  top,  gives  the  SW-cost  per  ship  in  relation  to  the  total  number  of  ships. 
There  is  a sharp  decrease  in  cost  if  a few  ships  became  a few  more,  and  only  a 
slight  decrease  if  many  ships  are  increased  by  a number.  Thus  especially  for  ships 
classes  with  a (very)  few  ships,  software  standardization  with  related  ships  is 
imperative!  Standardization  for  the  four  types  of  DAISY  into  one  DAISY-FAMILY 
considerably  reduced  the  SW  cost  in  the  RNLN,  not  only  for  the  initial  cost,  but 
even  more  impressive  during  the  life  cycle  maintenance!  (fig.  10,  bottom). 

*4.  DISCUSSION. 

In  the  author's  opinion  there  are  two  areas  of  software/system  engineering 
which  are  still  weak.  Both  are  ill-defined  areas,  both  are  more  or  less  covered  in 
literature,  but  a clear  overview  still  does  not  exist. 

4.1.  Functional  performance. 

Documents  as  "system  functional  description"  or  "system  performance 
specification"  are  often  discussed  between  tactical  data  systems  specialists.  Everybody 
has  his  personal  ideas,  and  there  is  a lot  of  common  feeling  about  such  a document  and 
the  necessity  for  it.  But  there  is  little  known  about  the  relations  between  the  system 
components,  hardware,  software,  menware  and  procedures. 

No  systems-engineering  technique  is  known  that  tells  the  optimum  balance  between  the 
system  components  (hardware,  software,  man-ware,  procedures)  in  order  to  achieve 
FOR  A GIVEN  AMOUNT  OF  MONEY  THE  MAXIMUM  GUARANTEED  OPERATIONAL/FUNCTIONAL 
PERFORMANCE,  AND  WICH  OPTIMUM  VAN  BE  DEMONSTRATED. 

A lot  of  work  e.g.  on  system  specifying  languages  is  already  done,  but  the  creative 
operational/functions  areas  are  becoming  so  complex  that  there  is  a strong  need  for  a 
systematic  approach,  (figure  11). 

4.2.  Quality  assurance  in  systems. 

Quality  assurance  is  a well  known  item,  especially  in  military  equipment,  and 
a lot  of  work  on  quality  assurance  on  software  is  already  done.  But  NATO  did  not  start 
before  1978  with  the  first  committee  on  software  quality  assurance!  On  the  systems  side 
of  software  there  is  a big  gap:  What  are  objective  criteria?  Can  they  be  measured  and 
reproduced?  Is  in  systems,  whose  performance  rely  mainly  on  software,  a functional 
software  test  suffucient  to  measure  the  performance? 

To  find  tools  to  adequately  ASSURE  us  that  software/ systems  have  a garanteed 
performance  is  imperative  for  the  early  '80's. 


s 
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DISCUSSION 


Brault 

Yesterday  Mr  Barnum  stated  th«u  military  people  at  high  level  are  very  reluctant  to  use  computers  for  making 
decisions  in  command  and  control.  This  may  be  due  to  the  fact  that  they  do  not  understand  how  the  software 
was  written  and  have  no  capability  to  modify  the  programs  in  real  time.  Did  you  experience  the  same  difficulties 
in  the  Netherland  Navy  and  if  so  how  did  you  overcome  them? 

Author’s  Reply 

The  answer  is  yes  and  no.  On  the  one  side  there  are  high  ranking  officers  who  do  believe  in  automation  for  routine 
jobs  but  who  really  do  not  believe,  or  want  to  believe,  in  computers  for  decision  making  or  assistance  to  decision 
making.  On  the  other  hand  we  found  that  where  the  computer  assists  the  decision  making  based  on  some  pre- 
assumption, users  of  the  systems  tend  to  heed  the  computers  advice.  These  users  were  trained  well  in  using  the 
systems  and  knew  its  limitations.  This  illustrates  well  that  high  integrity  systems  are  used  with  confidence  even 
in  decision  making  processes.  Apart  from  this,  we  feel  that  decision  making  by  automated  systems  still  is  a weakly 
defined,  unexplored  area.  There  are  good  possibilities  for  the  future. 
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RESOURCE  ANALYSIS  FOR  DATA- PROCESSING  SOFTWARE 

Edward  N.  Dodson 
General  Research  Corporation 
P.0.  Box  6770 

Santa  Barbara,  California  93111 
SUMMARY 


This  paper  summarizes  recent  work  sponsored  by  NASA  and  the  US  Air  Force  to  develop  life-cycle  cost  relation- 
ships for  data  processing  software.  The  primary  approach  has  been  to  develop  statistical  relationships 
based  upon  actual  experience  on  weapons  and  space  programs.  Cost-estimating  relationships  (CERs)  are  pre- 
sented for  major  phases  of  the  software  life  cycle,  and  for  major  variations  in  software  characteristics 
and  acquisition-management  concepts. 

Specific  impacts  on  software  cost  are  discussed  for  (1)  the  effects  of  hardware  capacity-constraints,  (2)  the 
effects  of  execution- time  constraints,  (3)  choice  of  language  type,  and  (4)  use  of  structured  programming 
procedures.  Also  discussed  is  ongoing  work  to  examine  the  interrelationships  among  the  life-cycle  phases, 
together  with  their  influence  on  software  costs. 

1 . INTRODUCTION 


There  is  growing  recognition  that  the  development  and  use  of  computer  software  requires  a major 
commitment  of  resources.  The  costs  of  developing  software  for  individual  large-scale  military  and  space 
systems  have  ranged  upward  from  tens  of  millions  of  dollars  to  nearly  a hundred  million  dollars  for  pro- 
grams such  as  Safeguard  or  Apollo.  Many  observers  have  noted  that  software  costs  now  far  exceed  associated 
hardware  development. 

The  analysis  of  software  poses  a number  of  challenges  that  stem  from  fundamental  distinctions 
between  hardware  and  software.  Among  these  are  the  following: 

• Most  hardware  elements  can  be  associated  directly  with  a single  functional  purpose  (detect 
airplanes,  transmit  data,  etc.).  Software,  on  the  other  hand,  often  serves  an  integrating 
role,  tying  together  the  individual  functions  of  a number  of  hardware  elements — thus  com- 
plicating the  problem  of  describing  the  functional  "output”  of  software  development  (i.e., 
what  the  software  does). 

• In  addition  to  problems  of  defining  the  functional  output  of  a software  development  program, 
it  is  also  comparatively  difficult  to  define  and  measure  its  more  directly  described 
"physical"  output.  Number  of  lines  of  code  is  one  measure,  but  this  can  be  ambiguous, 

with  differences  in  source  versus  object  code  together  with  questions  such  as  how  much  of 
the  code  is  new  programming,  how  much  was  developed  but  not  delivered,  whether  COMMENT 
cards  are  Included  in  the  line  count,  etc. 

• Another  significant  problem  with  software  cost  analysis  grows  out  of  the  fact  that  actual 
software  costs  have  not  been  recorded  in  detail  comparable  to  that  available  for  hardware 
programs.  In  many  cost  reports  for  weapon  systems,  the  hardware  costs  will  be  itemized  in 
considerable  detail,  while  all  the  software  expenditures  are  reported  as  a single-line 
item. 

In  spite  of  these  difficulties,  there  has  been  significant  progress  in  the  development  of  cost 
analysis  procedures  and  specific  quantitative  cost  estimating  relationships  (CERs)  for  software.  This 
paper  discusses  elements  of  this  work  which  we  have  carried  out  in  studies  sponsored  primarily  by  the  US 
Air  Force  and  by  NASA. 

While  I speak  of  "significant  progress,"  the  fact  remains  that  cost  analysis  of  software  programs 
is  still  an  uncertain  process.  The  purpose  of  this  paper  is  to  present  an  interim  report  of  the  results  of 
recent  work  towards  an  ultimate  goal  of  improving  techniques  for  predicting  the  costs  of  new  software  pro- 
jects. 

2 COST  ANALYSIS  OF  COMPUTER  SOFTWARE 


The  basic  objectives  of  our  software  cost  analyses  have  been  twofold: 

• Develop  comprehensive  life-cycle  CERs  so  that  all  costs  associated  with  software  develop- 
ment and  use  may  be  taken  into  account,  and 

• Develop  CERs  which  are  sufficiently  detailed  to  permit  choices  among  the  major  technical 
and  management  characteristics  of  software  projects. 

Another  goal  of  our  studies  has  been  the  development  of  CERs  which  can  be  used  at  early  stages 
in  the  acquisition  life  cycle.  Thus,  the  estimating  relationships  should  not  be  based  upon  detailed 
design  descriptors  which  can  be  identified  only  after  extensive  design  and  coding. 


The  ultimate  goal  of  the  resource-analysis  model 
this  might  include  number  of  targets,  data  rate, 
and  time).  This  has  been  accomplished  with  some 
similar  descriptors  for  the  functional  output  of 


is  to  relate  functional  output  (e.g.,  for  a radar  system, 
airspace  volume,  etc.)  to  resource  Inputs  (e.g.,  cost 
success  for  many  hardware  elements.  However,  developing 
software  has  proven  to  be  more  difficult. 
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Our  basic  approach  Co  Che  analysis  of  sofcvare  costs  Is  parametric  cose  analysis.  The  parametric 
method  Involves  the  analysis  of  related  historical  "actuals”  in  order  to  infer  the  costs  of  future  systems, 
equipment,  or  software.  Techniques  of  statistical  Inference  and  engineering  analysis  are  part  of  the  overall 
method.  Costs  appear  as  dependent  variables  in  est lmat lng^equat ions , with  the  Independent  variables  being 
selected  performance,  design,  or  "management"  descriptors. 

The  following  paragraphs  address- 

• Identification  of  Software  Cost  Determinants 

• Estimation  of  Software  Costs  by  Development  Phase 

• Consideration  of  Interrelati  iships  Among  Life-cycle  Phases 

2.1  Identification  of  Software  Cost  Determinants 

As  part  of  our  software  studies  we  have  carefully  surveyed  the  literature  on  software  cost 
analysis  (see,  e.g.,  BROOKS,  F.,  1975,  CLAPP,  J.  A.,  1976,  DEVENUY , T.  J.,  1976,  GEHRING,  P.F.,  1976, 

MORIN,  L,  1973,  PIETRASANTA,  A.  M. , 1970,  Trainer,  W.L.,  1974  and  US  AIR  FORCE,  1974),  and  discussed 
software  costs  with  knowledgeable  personnel  in  government  and  industry.  These  sources  have  employed  a 
great  variety  of  cost-determinants,  however  those  which  we  have  found  to  be  most  significant  include 
(1)  size,  (2)  execution- time  constraints,  (3)  memory-capacity  constraints,  (4)  language,  and  (5)  manage- 
ment approach. 

Size  of  the  software  is  a primary  measure  of  output,  and  is  an  obvious  cost  determinant. 

However,  accounting  for  the  number  of  lines  of  code  raises  a number  of  issues  which  are  addressed  sub- 
sequently. 


A cost-size  relationship  must  then  be  modified  by  a number  of  other  considerations.  Among 
the  most  significant  are  any  execution- time  and  memory-capacity  constraints  that  may  be  imposed  upon 
the  programmer.  "Real-time"  is  a descriptor  generally  used  to  indicate  time-constrained  programs 
(although  this  is  not  completely  accurate).  Many  applications  programs  are  time-constrained. 

Capacity  constraints  are  a "fact  of  life"  for  most  military  and  space  avionics  systems. 

Each  of  these  determinants  has  been  addressed  in  our  studies. 

Other  significant  cost  determinants  include  the  choice  of  language  (the  basic  choice  being 
between  assembly  language  and  a higher  order  language,  or  HOL) , and  a choice  of  management  techniques. 

This  latter  choice  includes  the  variety  of  management  procedures  which  is  widely  discussed  under  the 
title  of  "Structured  Programming." 

2.2  Estimating  Software  Costs  by  Development  Phase 

The  following  paragraphs  summarize  the  CERs  we  have  developed  for  the  various  phases  of  the 
software  life  cycle.  These  equations  are  written  for  a specific  set  of  conditions,  namely: 

1.  All  code  is  written  in  assembly  language. 

2.  The  code  is  largely  time-constrained  (or  "real-time"  code). 

3.  The  code  is  not  developed  under  Structured  Programming  procedures 
Variations  from  these  conditions  are  examined  in  Sec.  2.3. 

The  first  phase  we  have  identified  for  tne  software  acquisition  process  is  Analysis.  However, 
to  a large  degree  Analysis  is  not  a software  activity,  per  se.  Included  in  the  Analysis  phase  is  develop- 
ment of  the  basic  mathematics  of  the  system  process  (e.g.,  the  equations  of  motion  for  a body  in  orbit 
around  an  oblate  spheroid  with  an  irregular  gravitational  field).  Thus  the  effort  required  is  strongly 
influenced  by  the  state  of  knowledge  in  particular  scientific  and  engineering  fields — and  the  degree  to 
which  some  new  system  will  extend  that  knowledge.  The  complexities  of  this  process  are  not  directly 
related  to  the  complexities  of  coding  the  resultant  algorithms.  Thus,  Analysis  will  remain  largely 
non-parametrically  related  to  characteristics  of  the  software.  We  did  compile  data  which  included  the 
software  personnel  associated  with  Analysis  and  Design.  Consequently,  we  have  combined  these  two  phases 
as  far  as  estimating  the  effort  required  of  software  personnel. 

Analysis  and  Design.  In  the  course  of  our  software  cost  studies  we  obtained  data  from  the 
Boeing  Company,  from  a GRC  project  and  other  industry  sources,  and  from  a study  of  the  Apollo  program 
(RANKIN,  D.,  1972).  Using  these  data  we  developed  the  CER  shown  graphically  in  Fig.  1. 

Coding.  Using  the  same  data  sources  noted  in  the  preceding  paragraph,  we  derived  a CER  for 
the  Coding  phase  as  shown  in  Fig.  2. 

Testing.  A corresponding  estimating  relationship  for  testing  is  shown  in  Fig.  3. 


* 

The  other  basic  approach  to  cost  estimation  is  the  Industrial  Engineering  approach,  in  which  very 
detailed  assessments  of  labor,  material,  and  unit  costs  are  made.  These  are  then  summed  to  develop 
total  costs.  This  approach  relies  upon  specific  design  details  which  are  generally  not  available 
during  early  phases  of  the  system  Hfe  cycle. 


Maintenance.  A set  of  data  about  this  phase  of  the  software  life  cycle  was  available  in  the 
ADPREP.  This  data  permits  an  assessment  to  be  made  of  the  number  of  maintenance  staff  required  as  a 
function  of  the  amount  of  code  and  the  language  used.  The  resulting  CERs  are  shown  graphically  in 
Fig.  4.  It  is  important  to  note  the  relatively  poor  fit  (i.e.,  the  equations  do  not  account  for  even 
50  percent  of  the  inherent  variance  in  the  sample).  However,  more  recent  data  generally  corroborate 
these  findings. 

2.3  Identification  of  Additional  Cost  Relationships 

The  preceding  section  set  forth  cost-estimating  relationships  for  the  development  of  software 
which  is  (1)  coded  in  assembly  language,  (2)  developed  under  conditions  of  execution-time  constraints, 
and  (3)  not  developed  under  the  procedures  of  "Structured  Programming."  This  section  discusses  cost 
relationships  for  variations  from  each  of  these  conditions. 

Assembly  Language  Versus  Higher  Order  Language.  The  fundamental  distinction  in  software  lan- 
guage is  between  (1)  assembly  language,  or  machine-oriented  language,  and  (2)  higher  order  language  (HOL) . 
We  examined  several  sets  of  data  to  ‘develop  quantitative  assessments  of  language  as  a cost  determinant. 

The  choice  of  language  should  have  little  effect  upon  the  activities  of  Analysis  and  Design;  these  acti- 
vities are  not  concerned  with  specific  languages.  Subsequent  phases,  however,  should  be  directly  affected 
by  the  choice  of  language.  However,  we  do  not  have  direct  data  which  includes  cost  by  phase  and  variations 
in  language.  The  ADPREP  data,  which  does  include  variations  in  language,  is  for  total  development. 

Using  the  ADPREP  data,  several  relationships  were  examined.  The  statistics  for  the  resulting 
estimating  equations  are  unimpressive,  but  they  do  underscore  the  influence  of  HOL  upon  the  cost  of  soft- 
ware development.  The  coefficients  of  the  language  term  indicate  that  assembly  language  programs  are 
approximately  two  to  five  times  more  expensive  to  develop  per  object  instruction. 

Brooks  and  others  indicate  that  the  benefits  of  HOLs  extend  beyond  software  development.  The 
use  of  HOLs  "will  result  in  more  easily  maintained  software,  more  readily  changed  software,  more  reliable 
code..."  (US  AIR  FORCE,  1974).  The  ADPREP  data  also  include  information  about  maintenance  staffing  for 
various  programs.  Figure  4 indicates  the  difference  in  maintenance  staffing  for  programs  written  in 
assembly  language  versus  HOL.  Here  again,  the  two-to-f ive-fold  increase  in  assembly  language  cost  is 
applicable. 


Time-Constrained  Programming.  It  is  difficult  to  develop  software  in  which  prescribed  functions 
must  be  executed  within  stringent  time  constraints.  The  organization  of  memory  storage  and  the  sequencing 
of  instructions  and  subroutines  is  much  more  complex.  Wolverton  observed  that  "the  cost  of  producing 
real-time  (or  time-critical)  software  is  three  times  more  costly  than  non-real-time  software."  (WOLVERTON, 
1974). 


From  other  data,  the  cost  difference  is  not  so  clearly  established.  Figure  5 is  a graph  showing 
the  data  from  PARMIS  and  ADPREP,  together  with  data  obtained  from  Boeing  and  other  sources.  The  same 
(approximately  three-to-one)  ratio  can  be  seen.  However,  there  is  considerable  variability  in  the  data. 

Another  set  of  data  is  given  in  Stephenson  in  his  summary  of  SAFEGUARD  software  (STEPHENSON, 
1976).  Again,  with  considerable  variability  one  can  see  a roughly  3:1  ratio.  The  advantages  of  adequate 
time-margins  also  extend  to  verification  and  maintenance  activities.  With  sufficient  time  for  program 
execution,  more  attention  can  be  given  to  clarity  and  conformance  to  standards,  and  software  diagnostic 
and  self-checking  features  can  be  employed. 

The  CERs  developed  in  Sec.  2.2  are  for  code  which  is  largely  time-constrained.  Thus  If  these 
cost  relationships  are  to  be  used  for  non- time-constrained  software,  the  cost  figures  can  be  divided  by 
three  (subject  to  the  hazards  noted  above). 

Structured  Programming.  One  of  the  most  widely  discussed  topics  in  the  software  literature 
is  Structured  Programming.  Some  authors  suggest  this  is  a wondrous  new  procedure;  others  are  more  reserved, 
saying  it  is  nothing  more  than  just  being  orderly. 

A reasonable  consensus  is  that  it  involves  several  specific  procedures,  including: 

1.  Top-down  programming:  This  requires  that  software  design  and  code  be  developed  from  the 
level  of  control  logic  down  to  the  detailed  logic  level. 

2.  Structured  coding:  Each  block  of  code  is  developed  by  adhering  to  a 9trict  set  of  rules, 
and  to  a limited  number  of  permissible  sequences,  such  as: 

• Simple  sequences,  in  which  one  operation  follows  another  with  no  branching  alterna- 
tives 

• Selection  sequences,  in  which  either  of  two  operations  may  be  used  depending  on 
a comparison  or  test 

• Repetition  sequences,  in  which  a set  of  instructions  is  repeated  until  some  condi- 
tion is  fulfilled,  at  which  time  the  loop  is  exited. 


* 

ADPREP  refers  to  the  ADP  Resource  Estimating  Procedure;  the  data  were  reported  by  Planning  Research 
Corporation  in  Report  R-152,  August  1970.  Other  data  sources  noted  in  this  paper  Include  PARMIS 
(Planning  and  Resources  Management  Information  System)  at  the  Air  Force  Data  Systems  Design  Center. 
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In  short,  these  are  straightforward  sequences  with  single  points  of  entry  and  exit  (there 
are  no  GO  TO  statements).  Another  rule  is  that  modules  of  code  should  be  no  longer  than 
a single  page. 


3.  Support  Libraries;  This  is  a centralized  repository  for  the  blocks  of  code  throughout 

their  development.  The  librarian  is  responsible  for  record-keeping  and  file  maintenance, 
thus  contributing  to  a more  efficient  division  of  labor  (programmers  can  concentrate  on 
programming) . 

There  is  little  definitive  evidence  which  precisely  determines  the  cost  impacts  of  structured  programming. 
However,  data  from  IBM,  Safeguard,  (NICHOLS,  1975),  and  other  sources  clearly  indicate  that  there  are  two- 
to-five-fold  cost  savings  for  both  development  and  maintenance. 

2.4  Consideration  of  Interrelationships  Among  Life  Cycle  Phases 

The  preceding  CERs  have  been  developed — in  large  part — for  individual  phases  of  the  software 
life  cycle.  These  CERs — and  others  we  have  developed  or  have  found  in  the  literature — still  exhibit 
considerable  lack  of  precision.  Thus,  in  our  studies  for  the  Air  Force  and  NASA  we  began  to  explore 
additional  factors  which  might  explain  the  variation  in  observed  costs. 

From  this  point  of  departure  we  identified  factors  other  than  characteristics  of  each  indivi- 
dual phase;  namely,  a number  of  significant  interrelationships  among  phases  of  the  software  life  cycle. 

These  complicate  the  process  of  identifying  cost  determinants  for  each  individual  phase.  To  elaborate: 
our  general  approach  to  estimating  the  costs  of  a given  activity  is  to  focus  on  specific  attributes  of 
the  activity  which  most  strongly  influence  its  cost.  However,  we  find  that  a significant  element  in 
explaining,  say,  the  cost  of  testing  is  the  effort  given  to  the  earlier  activity  of  software  design.  We 
believe — in  effect — that  there  exists  the  type  of  relationship  shown  in  Fig.  6.  Over  some  range,  this 
curve  indicates  if  the  effort  given  to  design  is  reduced , there  will  be  added  effort  required  during  the 
testing  (as  well  as  coding)  phases  because  of  errors  and  difficulties  with  the  program.  Conversely, 
additional  time  spent  in  design  of  the  software  will  reduce  subsequent  effort  required  for  testing  (and 
for  coding). 

Similar  arguments  can  be  made  about  relationships  between  resources  expended  in  codirg  or  testing 
and  the  subsequent  effect  upon  required  maintenance  resources  after  the  software  is  installed.  \ these 
cases,  man-months  of  coding  or  man-months  of  testing  would  be  the  abscissa,  and  man-months  of  error  correc- 
tion in  maintenance  would  define  the  ordinate.  We  are  currently  exploring  these  relationships,  the  most 
important  of  which  is  hypothesized  to  be  between  design  and  the  subsequent  testing  period.  Our  initial 
studies  of  these  interrelationships  have  been  inconclusive.  We  have  not  been  able  to  compile  sufficient 
data  to  prove  (or  disprove)  the  hypotheses  noted  above.  This  remains  as  a topic  for  further  research. 

Other  continuing  research  activities  include  the  following: 

• Development  of  software  sizing  relationships  in  terms  of  basic  mission  descriptors  (e.g., 
for  surveillance  systems,  the  number  of  lines  of  code  as  a function  of  number  of  targets, 
target  speeds,  range  resolution,  etc.) 

* 

• Development  of  specific  hardware-software  tradeoff  relationships 

• Evaluation  of  the  impact  of  Verification  and  Validation  (V&V)  upon  acquisition  and  main- 
tenance costs  of  software 

• Development  of  cost  control  and  cost  reporting  procedures  for  ongoing  projects. 


i 


i 

* 

As  an  example,  we  have  addressed  the  cost  Impacts  upon  software  development  associated  with  hardware 
capacity-constraints.  Increasing  this  capacity  does,  however,  mean  that  the  costs  of  hardware  will 
be  increased. 
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ASSEMBLY-LANGUAGE 


Maintenance  Requirements  for  Machine-Language  and  High-Order-Language  Programs 


DISCUSSION 


A.  Hofmann 

Your  Figure  4 is  easily  misinterpreted;  isn’t  it  in  favor  of  HOL,  since  HOL  requires  only  one-third  to  one-quarter 
of  maintenance  effort?  Actually  a program  written  in  HOL  will  be  about  3 to  4 times  the  size  after  compilation  of 
the  one  written  in  assembly  language.  Conclusion;  Equal  maintenance  for  HOL  and  assembler  programs. 

Author's  Reply 

The  data  I have  suggests  that  the  HOL  assembly  multiplier  is  generally  less  than  3 which  still  leaves  an  HOL  advantage. 
I agree  that  the  figure  as  it  stands  - is  misleading. 


J.  Shepherd 

Have  you  been  able  to  determine  any  cost  relationships  between  the  level  of  integrity  required  by  software  and  the 
support  software  (assembler  or  HOL  etc.)  used? 

Author’s  Reply 

No;  we  have  not  attempted  to  identify  this  relationship;  nor  do  I know  of  any  work  by  others. 


W.F.Neuberger 

How  do  you  estimate  the  number  of  instructions  needed  at  the  beginning  of  a program? 

Author’s  Reply 

I know  of  some  work  we  have  done  to  develop  crude  estimates  of  size  for  space  navigation  software,  and  others 
(I  believe  Mitre)  have  done  for  air  defense  systems  software.  In  the  latter,  size  = f (range  of  coverage,  target 
resolution,  data  rates  for  target  info...).  Otherwise,  not  much  has  been  done  that  I know  of  - in  this  field. 


R.  Nelson 

(1)  How  far  back  into  the  system  design  effort  do  you  carry  the  software  costing  effort? 

(2)  In  particular,  have  you  done  or  do  you  know  of  any  studies  relating  the  total  software  cost  of  a system  to  the 
amount  of  involvement  of  software  people  in  the  system  engineering  process? 

Author’s  Reply 

(1)  We  have  gone  back  into  the  analysis  phase,  but  have  found  required  resources  are  not  functionally  related  to 
characteristics  of  the  software.  Rather,  they  are  a function  of  the  state  of  knowledge  in  the  field  which  the 
software  is  serving  (e.g.  air  defense,  space  navigation,  etc.).  Analysis  is  concerned  with  developing  basic 
algorithms  which  will  then  be  implemented  in  software  (and/or  hardware).  The  effort  required  to  do  this  is 
not  functionally  related  to  the  eventual  softwares  characteristics. 

(2)  Ido  not  know  of  any  studies  which  have  related  total  software  costs  to  early  involvement  in  the  engineering 
process. 


In  critical  functions  on  aircraft  and  spacecraft,  verification  and  validation  (V &V)  is  essential.  What  is  the  impact 
of  V&V  on  the  total  cost  of  the  software? 


Author’s  Reply 

I have  some  data  on  the  cost  of  V&V  plus  some  information  on  the  benefits, 
as  follows; 


These  benefits  have  been  “measured” 


No.  of 

“problems”  incurred 
in  operation 


Program  size 
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SUMMARY 

A set  of  standards  is  described,  the  adoption  of  which  should  allow  computer-based  military  equipments  from 
a variety  of  sources  to  be  developed  in  compatible  fashion.  Such  standards  are  held  to  be  necessary  in 
the  face  of  an  increasing  proliferation  of  small  processor  types.  It  is  suggested  that,  without  adoption 
of  such  standards,  the  current  logistic  and  training  problems  of  the  Armed  Forces  will  increase 
significantly  as  small  computer-based  equipments  come  into  service. 

1.  INTRODUCTION 

The  severe  disparity  between  the  timescale  surrounding  computer  evolution  and  that  for  the  introduction  of 
computer-based  systems  into  military  equipment  is  illustrated  in  Table  1 for  2 UK  Naval  developments. 

The  situation  is,  however,  significantly  worse  than  shown  in  the  table,  since  such  equipments  are 
currently  expected  to  remain  in  service  use  for  the  hull-life  of  a ship  (up  to  20  years).  Similar 
examples  could  be  quoted  for  Army  or  Air  Force  projects.  Effectively  the  Armed  Services  are  being  put  in 
the  position  of  having  to  maintain  technologies  well  beyond  the  timeframe  of  their  commercial  viability. 
This  brings  the  attendant  problems  of  producing  such  technologies,  and,  when  this  is  no  longer  possible, 
of  finding  good  quality  personnel  who  are  prepared  to  provide  post  design  expertise  in  such  support. 

With  computer-based  systems  the  situation  to  date,  though  difficult,  has  perhaps  been  manageable  since 
architectures  in  use  have  been  centralised  and  the  range  of  computer  types  limited.  This  position  is  now 
changing  rapidly  with  the  advent  of  mini-computer  and  microprocessor-based  weapons  and  distributed 
information  systems.  It  is  the  authors’  contention  that,  unless  such  equipments  are  as  far  as  possible 
developed  around  a set  of  common  standards,  the  already  difficult  task  of  maintaining  such  equipments  in 
the  future  will  grow  significantly.  It  is  proposed  that  this  task  can  be  eased  by  adoption  of  the 
following: 

(a)  Military  mini-computers  and  microprocessors  that  are  code  compatible  with  the  machine 
code  of  a successful  commercial  machine. 

(b)  A defined  high-level  language  for  program  development. 

(c)  Formalised  support  software  for  controlling  real-time  interactive  application  processes 
in  an  orderly  fashion. 

(d)  A common  internal  bus  structure  for  store  and  peripheral  interfacing. 

(e)  A defined  high-level  serial  interface  for  linking  computers. 

(f)  An  equipment  practice,  specifying  board  size,  connector  type,  cooling  and  power 
distribution  philosophy. 

None  of  these  items  is  independent  of  the  others  and  it  is  asserted  that  the  adoption  of  a subset  only 
would  be  undesirable.  The  rest  of  this  paper  is  devoted  to  a more  detailed  description  of  the  set  of 
specific  standards  proposed  as  meeting  this  need  for  UK  purposes. 

2.  HIGH-LEVEL  LANGUAGE  (CORAL)  AND  SUPPORT  SOFTWARE  CONSIDERATIONS 

The  availability  of  good  support  software  is  a vital  ingredient  in  the  success  of  any  project  which  is 
procuring  computer-  sed  equipment.  The  term  covers  that  standard  "off-the-shelf"  software  which  is 
common  to  all  projects  whether  it  is  used  during  development  only,  or  incorporated  in  the  final 
operational  system.  In  overview,  it  falls  into  3 categories: 

(a)  Software  to  support  the  development  of  the  "Application  Software",  normally  known  as 
the  "Program  Development  System",  including: 

(1)  A multi-access  operating-system  with  a good  backing-store  file  handling  system. 

(2)  A good  CORAL  66  compiler. 

(3)  A procedural  library. 

(4)  A compatible  interactive  and  batch  source-text  editor. 

(5)  Source  text  composition  and  layout  aids. 

(6)  Debugging  aids. 

(7)  Specialised  application  testing  and  checkout  aids. 

(b)  Sc'  a -e  to  support  the  running  of  the  Application  software,  therefore  including: 

(1)  The  "Real-Time  Executive",  MASCOT  (see  later). 
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(2)  An  Input -Output  package  to  work  with  MASCOT. 

(3)  A procedural  library. 


! 
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(c)  Test  Software,  which  provides  one  (of  several)  mechanisms  for  checking  out  the  computer 
hardware  during  commissioning,  operational  switch-on,  fault  identification  or  maintenance. 

Two  important  observations  may  be  made  concerning  the  application  support  software  (Category  (b)).  The 
first  is  that  this  software  is  the  most  difficult  to  standardise  on  for  a particular  computer,  because  it 
intimately  affects  the  performance  of  the  final  system.  Hence  it  must  be  an  acceptable  and  agreeable 
standard  to  the  users  in  theory  and  practice,  and  one  which  can  be  machine  independent.  We  believe  we 
have  found  this  goal  in  MASCOT  (see  later) . 

The  second  observation  is  that  the  traditional  "Program  Development  System"  cannot  support  the  majority 
of  Real-Time  applications,  briefly  because  of  run-time  efficiency  considerations.  Thus  Categories  (a) 
and  (b)  have  tended  to  be  separate  developments  in  the  past.  This  is  a pity  because  there  is  potentially 
a large  amount  of  common  software,  and  more  seriously  the  testing  of  the  application  software  is 
complicated  by  the  transition  between  the  2 environments.  The  future  here  must  be  for  the  Program 
Development  System  to  be  built  upon  the  Real-Time  Executive,  as  is  possible  with  MASCOT. 

In  the  current  state-of-the-art,  the  approach  of  basing  a military  computer  on  a viable  commercial  order 
code  offers  at  least  a ready  made  and  maintainable  Program  Development  System.  This  must  include,  for 
UK  MOD  purposes,  support  of  the  MOD  preferred  high  level  language,  CORAL  66  (HMSO  1970).  This  language 
is  block-structured,  similar  to  ALGOL  60,  but  gives  more  efficient  code  generation.  It  is  suitable  for 
real-time  applications  by  the  provision  of  machine-code  inserts  as  a means  of  flexibly  interfacing  to  the 
external  environment,  rather  than  by  the  inclusion  of  particular  "real-time"  features  which  in  any  case 
would  now  be  out  of  date.  After  12  years  of  service  CORAL  66  compilers  are  available  for  S5  computer 
models,  of  which  12  are  fully  MOD  approved.  Compilers  for  a further  28  models  are  under  development, 
bringing  coverage  up  to  24  manufacturers.  "Standardising"  on  CORAL  66  has  the  advantage  of  avoiding  the 
need  to  support  other  languages,  even  assemblers. 

The  notion  of  a "CORAL  machine"  was  a major  factor  in  the  choice  of  the  Ferranti  Argus  700  computer  range 
as  the  baseline  for  a military  computer.  The  efficiency  of  a CORAL  program  at  runtime  depends  not  only 
having  a compiler  which  produces  efficient  code,  but  also  on  having  an  architecture  which  is  convenient 
for  code  generation.  The  Argus  700  architecture  was  designed  from  the  start  to  be  "CORAL  conscious". 

Also  with  Argus  700  came  the  support  software,  covering  the  items  listed  (except  Item  (a)(6)),  whose 
development  is  measured  in  units  of  man-centuries  rather  than  man-years.  Naturally,  the  support  software 
is  centred  around  CORAL  and  is  largely  written  using  it. 

3.  MASCOT  - A FORMALISED  REAL-TIME  SUPPORT  SOFTWARE  METHODOLOGY 

MASCOT  (Modular  Approach  to  Software  Construction,  Operation  and  Test  ) now  possesses  a UK  Official 
Definition  (MASCOT  Suppliers  Association  1978).  MASCOT  is  a set  of  facilities  for  real-time  programming, 
incorporating  features  concerned  with  systems  development  and  construction.  It  is  intended  to  influence 
and  assist  all  stages  in  the  life  cycle  of  a software  system,  from  initial  design  to  maintenance  and 
modification.  MASCOT  provides: 

(a)  A formalised  methodology  for  expressing  the  software  structure  of  a multi-programmed  or 
real-time  system  which  can  be  independent  either  of  computer  configuration  or  programming  language. 

(b)  A disciplined  approach  for  design,  implementation  and  testing  giving  a concept  of 
modularity  for  real-time  systems  and  increased  reliability  by  formal  control  over  access  to  data. 

(c)  An  interface  to  support  implementation  and  testing  methodologies  both  through  a small 
kernel  which  can  be  implemented  directly  on  a bare  machine  or  on  top  of  a host  operating  system  and 
through  software  construction  facilities. 

(d)  A strategy  for  documentation. 

The  total  set  of  MASCOT  facilities  is  shown  in  Figure  1 and  the  definitions  of  formal  terms  used  in  this 
diagram  are  given  in  the  appendix  to  this  paper.  All  MASCOT  implementations  are  required  to  provide  the 
synchronisation  primitives  (JOIN,  WAIT,  LEAVE,  STIM) , the  suspension  primitive  (SUSPEND)  and  the 
termination  primitive  (ENDROOT) . All  bare  machine  implementations  must  provide  an  interrupt  handler  and 
all  evolutionary  implementations  must  include  construction  facilities,  sub-system  control  facilities,  a 
command  language  interpreter  and  a monitor  facility.  The  additional  facilities  shown  in  Figure  i are 
optional.  It  is  intended  that  operational  systems  may  be  deemed  'FROZEN'  and  based  around  MASCOT 
implementations  containing  no  construction  facilities. 

An  example  of  one  level  of  MASCOT  documentation  is  an  Activity  Channel  Pool  (ACP)  diagram  as  shown  in 
Figure  2.  Activities  are  processes  which  operate  independently  and  asynchronously,  and  which  co-operate 
by  accessing  Intercommunication  Data  Areas  (IDAs),  these  latter  being  either  channels  supporting 
undirectional  data  transmission  or  pools  providing  permanent  or  semi -permanent  data  areas.  Channels  may 
have  a number  of  producer  activities  associated  with  the  input  interface  and  a number  of  consumer 
activities  associated  with  the  output  interface.  At  each  of  these  interfaces  MASCOT'S  mutual  exclusion 
facilities  prevent  access  by  more  than  one  activity  at  a time. 
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4. 


MILITARY  PROCESSOR  DESIGN 


An  entirely  novel  design  technique  has  been  developed  for  the  Military  Argus  Processor.  This  processor 
is  based  on  an  existing  range  of  commercial  machines,  and  uses  2901  4-bit  slices,  PROMs,  and  Programmed 
Logic  Array  chips.  It  is  constructed  on  a pair  of  6 in.  x 9 in.  cards  (Double  EUROCARDS),  with  an 
optional  third  store  card. 

The  microcode  for  the  new  processor  was  generated  and  tested  using  a new  HYBRID  simulation  technique, 
wherein  the  4-bit  slice  chips  which  make  up  the  heart  of  the  design  are  attached  to  a HOST  computer  via 
standard  TTL  I/O  parts.  An  area  of  core  store  is  set  aside  within  the  HOST  computer,  and  is  thought  of 
as  "belonging"  to  the  4-bit  slices.  It  is  called  PSEUDO  CORE.  Other  than  the  4-bit  slices  every  entity 
which  appears  in  the  new  computer  (ie  counters,  gates,  PROMs,  PLAs  etc)  is  simulated  very  precisely  by 
software  within  the  HOST.  What  amounts  to  a new  high-level  language  has  been  developed  for  this  purpose  - 
the  entire  operation  of  the  new  processor  -an  be  described,  down  to  the  waveform  level,  within  600  lines 
of  Teletype  listing. 

The  microcode  is  debugged  on  the  above  configuration  as  an  interactive  teletype  task.  The  entire  design 
is  checked  by  running  the  full  diagnostic  software  package  for  the  target  computer  within  the  PSEUDO  CORE, 
ie  before  any  hardware  is  constructed.  Once  the  design  has  been  finalised  and  fully  checked,  paper  tapes 
are  produced  automatically  from  the  simulation  for  directly  programming  the  PROM  and  PLA  devices  which 
make  up  the  bulk  of  the  new  design.  In  effect,  the  technique  reduces  the  fabrication  of  the  new 
processor  to  an  interactive  teletype  task,  since  virtually  all  of  the  intricate  wiring  is  now  within  these 
programmed  devices.  A further  significant  advantage  is  that  the  technique  is  self-documenting. 


S. 


SERIAL  SIGNALLING  STANDARDS 


The  hardware  concepts  being  advocated  are  illustrated  in  Figure  3,  which  shows  computers  constructed  on 
cards  of  defined  size,  to  a common  internal  interface  standard  and  communicating  with  each  other  by 
defined  serial  links.  Such  concepts  are  by  no  means  original;  by  and  large  a unique  set  is  adopted  by 
every  computer  manufacturer.  However,  only  in  a limited  number  of  available  serial  links  has  there  been 
any  significant  compatibility  to  date  between  the  standards  used  by  differing  manufacturers. 

International  standardisation  authorities  have  made  more  progress  in  the  furthering  of  these  serial 
standards  than  in  the  other  areas,  probably  for  the  pragmatic  reason  that  it  is  here  that  users  have  most 
strongly  encountered  a requirement  for  interaction  between  different  suppliers. 

It  is  in  this  area  also  that  one  can  most  readily  see  legitimate  reasons  for  divergence  between  Army,  Navy 
and  Air  Force  Systems,  since  there  are  significant  variations  in  scale  between  cable  links  employed  in 
aircraft  or  ships  and  on  battlefields.  There  are  a number  of  commercially  neutral  standards  available 
which  are  suitable  for  inter-processor  communication.  Specifically  these  may  be  listed  as: 

(a)  NATO  draft  STANAG  4153  for  shipbome  use. 

(b)  MIL  STD  1553A  for  aircraft  applications. 

(c)  HDLC.  Though  a proposed  commercial  standard,  HDLC  is  well  suited  to  certain  military 
applications,  and  its  adoption  now  would  offer  a real  prospect  of  military/commercial  compatibility  in  the 
future . 


In  addition  a requirement  has  been  identified  for  fully  broadcast  working  in  future  Naval  systems,  and  a 
paper  on  a proposed  solution  given  at  this  conference  (Wells  and  Stainsby  1978) . 


6. 


INTERNAL  INTERFACING  STANDARD  - MODBUS 


When  consideration  was  given  to  making  a recommendation  on  an  internal  computer  interfacing  standard,  the 
requirement  for  commercial  neutrality  left  little  alternative  but  to  start  afresh  and  define  a new 
standard.  There  are  in  existence  a number  of  apparently  suitable  interfaces  (the  best  known  in  the  PDP-11 
Unibus)  but  all  known  at  the  time  were  proprietary.  What  has  been  defined  is  our  implementation- 
independent  interfacing  standard,  known  as  MODBUS.  MODBUS  specifies  computer  information  transfer  and 
control  sequences  on  nominated  lines,  and  it  is  envisaged  as  being  applicable  to  a range  of  equipment 
practices.  Inclusion  of  MODBUS  in  a specific  equipment  practice  requires  association  of  the  nominated 
lines  with  specific  edge-connector  pins,  the  inclusion  of  necessary  power  supplies  and  shelf  fault- 
reporting logic. 

Devices  using  MODBUS  for  information  transfer  require  access  to  28  bussed  lines  eg: 

18  Address/Data  lines  (18  bit  Address  width,  16  bit  data  transfers) 

2 Byte  Working  lines  (Byte  Working,  Byte  Address) 

3 Cycle  Control  lines  (Cycle  Begin,  Cycle  Response,  Cycle  Finish) 

2 Access  Control  lines  (Bus  Grant,  Bus  Accept) 

2 System  Control  lines  (Reset,  Cycle  Abort) 

1 Interrupt  line 


Devices  which  wish  to  initiate  transfers  of  information  each  require  an  extra  Bus  Request  line  which  is 
connected  directly  to  a bus  arbiter  responsible  for  allocation  and  access  control.  A further  starred 
(to  the  arbiter)  line  (Interbus  Cycle  Response)  is  required  by  devices  performing  linking  operations  to 
another  bus.  A typical  system  is  shown  in  Figure  4. 


The  requirement  that  systems  be  constructed  from  a common  set  of  compatible  cards  has  had  2 significant 
design  consequences: 


(a)  Cards  in  a MODBUS-based  system  will  be  position  sensitive.  This  is  normal  engineering 
practice  in  the  majority  of  electronic  equipments,  and  in  MODBUS  it  allows  cards  of  like  type  to  be 
substituted  without  prior  setting-up  or  personalisation. 

(b)  System  specific  information  is  largely  concentrated  in  back-plane  wiring  and  the  bus 
arbiter  card. 

This  latter  may  contain  interrupt  routing  information  and,  for  optimum  performance,  specific  arbitration 
algorithms. 

To  ease  the  problems  of  conformity  with  specified  bus  waveforms  an  LSI  interface  set  is  being  developed. 

To  an  individual  device  designer  using  this  set,  the  processes  of  seeking  bus  allocation  and  the 
management  of  information  transfer  along  the  bus  will  be  invisible,  and  will  be  effected  by  a simple 
handshake . 

MODBUS  allocation  is  under  the  control  of  the  bus  arbiter  unit.  Though  the  exact  algorithm  for 
allocation  of  the  bus  by  the  arbiter  can  be  system  dependent,  the  basic  design  philosophy  is  such  as  to 
support  efficiently  cycle  by  cycle  allocation  between  those  units  bidding  for  use.  However,  a master 
wishing  to  retain  the  bus  for  successive  cycles  without  repetitive  allocation  requests  may  do  so,  unless 
its  permission  to  use  the  bus  is  withdrawn  by  the  arbiter.  As  far  as  possible  'look-ahead'  allocation  is 
employed  ie  allocation  of  the  bus  for  the  (N  + 1)  the  data  cycle  is  progressed  on  the  request  and  access 
control  lines  during  the  course  of  the  N th  data  cycle. 

The  normal  mode  of  information  transfer  across  the  bus  is  on  a master-slave  basis  ie  a device  having 
requested  and  been  granted  use  of  the  bus  initiates  a read,  write  or  vector  (address  only)  cycle. 
Information  transfer  during  these  cycles  is  regulated  by  the  3 cycle  control  lines,  and  all  events  are 
handshaken  so  that  devices  of  differing  speeds  may  be  connected  to  the  bus.  Transfers  which  fail  to 
elicit  a response,  or  which  violate  bus  rules,  will  be  terminated  by  the  arbiter  using  the  cycle  abort 
line.  Such  termination  will  not  affect  other  devices  using  the  bus,  but  good  system  practice  requires 
that  the  fault  condition  be  indicated.  Though  in  general  master  devices  must  release  the  bus  when  their 
permission  to  use  it  is  withdrawn  by  the  arbiter,  these  performing  indivisible  cycles  such  as  semaphore 
test-and-set  operations  may  retain  the  bus  for  2 successive  cycles. 

7.  EQUIPMENT  PRACTICE 

A new  equipment  practice  is  required  to  provide  a physical  realisation  of  the  modularity  concepts  which 
are  central  to  our  proposals.  The  term  equipment  practice  is  taken  to  include  not  only  cabinets,  racks 
and  cards  but  also  cooling,  power  supplies,  all  interconnections  and  the  provision  of  maintenance  and 
monitoring  facilities.  Some  commercially  neutral  standards  exist  in  equipment  practices,  as  well  as  a 
vast  range  of  individual  manufacturer's  approaches.  The  latter  were  rejected  on  the  grounds  that  they 
were  proprietary  and  as  such  it  was  felt  that  their  adoption  would  create  difficulties  in  bringing  them 
into  usage  and  in  maintenance.  Some  deeper  consideration  was  given  to  3 commercially  independent 
standards;  namely  ATR  (Aircraft  Transportable  Racking),  SEM  (Standard  Electronic  Modules)  and  CAMAC 
(Computer  Assisted  Measurement  and  Control). 

ATR  is  in  widespread  use  but  not  sufficiently  specified  to  be  the  complete  equipment  practice  which  we 
require. 

SEM's  were  rejected  on  the  grounds  that  the  card  size  was  felt  to  be  inadequate  for  construction  of  such 
functional  units  as  might  be  expected  to  result  from  reasonable  partitioning  in  a modem  computer  system. 
Examples  of  the  latter  are  processors,  32K  store  blocks  and  peripheral  drivers. 

CAMAC  standards  are  widely  used  in  the  nucleomics  and  instrumentation  fields.  They  form  a possibly  unique 
example  of  a voluntary  group  of  users  defining  and  maintaining  standards  which  are  willingly  followed  by  a 
range  of  manufacturers.  The  practice  itself  is  wide-ranging  and  well  defined.  However  it  was  considered 
unsuitable  on  the  grounds  that  it  could  not  be  re-engineered  to  military  standards  without  major  re-design 
In  addition  the  interfacing  bus  had  a number  of  limitations  when  viewed  against  our  general  purpose  data 
processing  requirements. 

Our  chosen  approach,  as  in  the  software  case,  was  to  adopt  the  commercial  equipment  practice  which  most 
nearly  met  our  requirements.  This  is  based  on  a 19  in.  rack  philosophy  using  Single  (100  x 160  mm)  and 
Double  (233.4  x 160  mm)  Eurocards,  these  standards  (part  of  the  DIN  41494  specification)  now  being  very 
widely  used  in  Europe.  There  are  2 connector  areas  on  Double  Eurocards  (MODBUS  being  confined  to  the 
top  connector  only)  and  the  associated  2-part  connector  (DIN  41612)  is  again  fast  becoming  the  commercial 
standard  in  Europe  (Mil  Version  VG  95324).  An  outline  Double  EuTocard  is  shown  in  Figure  5. 

Overall  design  philosophy  is  based  on  modularity  at  card  carrier  or  shelf  level,  each  of  these  Standard 
Equipment  Units  (SEU's)  having  an  associated  power  supply,  cooling  unit  and  cable  termination  area.  Thus 
one  such  unit  with  a suitable  cover  can  form  an  independent  small  system,  as  could  be  incorporated  in  a 
console,  or  a group  of  4 or  5 such  units  with  an  overall  cover  can  form  a conventional  cabinet. 

The  modularity  concepts  also  encompass  a range  of  power  supply  units  which  may  be  in  the  form  of: 


(a)  Small  pluggable  units  in  the  shelf. 

(b)  Larger  units  mounted  at  the  rear  of  the  shelf  behind  the  backplane  wiring. 

(c)  Large  units  which  provide  power  to  a whole  cabinet. 


Similar  flexibility  is  required  of  the  cooling  system.  To  cater  for  a wide  range  of  applications  3 main 
types  will  be  developed: 


(1)  Forced-air  circulation  through  the  shelf  venting  into  the  compartment.  This  should  form 
the  cheapest  system. 

(2)  Closed-circuit  forced-air  with  heat-exchanger  (air-to-water  or  air-to-air).  This 
approach  is  most  common  in  present  systems. 

(3)  A chilled-water  conduct  ion -coo led  system  where  it  is  required  to  remove  more  heat  than 
possible  under  (1)  or  (2),  or  to  operate  in  quiet  conditions. 

There  is  similar  flexibility  in  shelf  design  to  facilitate  incorporation  of  modules  etc  in  addition  to 
single  cards.  All  the  associated  parts  (cards,  shelves,  power  supply  units,  heat-exchanges  and  cabling) 
will  be  standardised.  Thus  any  future  system  can  be  built  up  from  standard  parts  with  new  items  being 
developed  as  necessary. 

8.  THE  WAY  AHEAD 

A set  of  standards  meeting  the  requirements  outlined  in  the  introduction  to  this  paper  has  been 
identified.  Their  expression  in  formal  terms  either  existed  (CORAL,  MIL  STD  1S53A)  was  in  hand  (MASCOT) 
or  has  been  deliberately  progressed  (MODBUS,  Equipment  Racking)  in  the  work  described  here.  Projects  in 
the  United  Kingdom  are  now  committed  to  developments  based  around  these  standards.  An  accurate 
assessment  of  the  benefits  of  application  of  what  is  advocated  can  only  be  made  in  the  future  by 
contrasting  through-life  costings  of  those  projects  which  have  conformed,  with  broadly  similar 
developments  based  around  differing  standards.  The  points  proposed  in  the  paper  will  have  a finite  life 
due  to  technological  advance,  and  it  is  necessary  that  a near-continuous  review  be  made  of  their 
relevance.  Even  today,  it  is  appreciated  that  not  all  military  computing  tasks  can  conform  to  the 
proposals,  electro-magnetic  signal  processing  being  an  example  of  a specialist  area  where  data-rates  are 
significantly  outside  the  scope  of  the  foregoing.  However,  there  exists  a significant  proportion  of 
United  Kingdom  operational  computing  tasks  that  will  benefit  in  development  from  adoption  of  these 
proposals,  and  these  benefits  should  increase  in  operational  use.  If  these  assumptions  are  correct,  then 
it  appears  reasonable  to  extrapolate  to  the  statement  that  adoption  of  these,  or  a similar  set,  by  NATO 
would  bring  benefit  on  a wider  scale,  not  least  being  interoperability  and  compatibility  of  computer-based 
equipments.  This  seems  a suitable  subject  for  discussion  in  this  forum. 
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Access  Procedure 


An  Activity  Channel 
Pool  (ACP)  diagram 


Activity 


Command  Language 
Interpreter 


Control  Queue 


Function 


Intercommun icat ion 
Data  Area  (IDA) 


Primitive 


DESCRIPTION 


The  class  of  procedure  used  to  operate  on  a Channel  or  Pool  data 
structure. 


A method  for  representing  a MASCOT  system  diagramatically. 


A single  thread  in  the  multi  processing  system  administered  by  the 
scheduler.  The  processing  actions  of  an  Activity  are  defined  by  its 
Root  Procedure.  The  interactions  of  an  Activity  with  other  Activities 
are  completely  confined  to  a set  of  IDAs  which  are  actual  parameters  of 
the  Root  Procedure. 


The  means  whereby  Kernel  functions  are  made  available  to  the  user  in 
an  Evolutionary  system. 


The  object  in  the  Data  Structure  of  an  IDA  which  provides  the  focal 
point  for  software  stimulation  and  mutual  exclusion  of  one  activity  by 
another,  by  means  of  the  Primitive  operations  WAIT  and  STIM,  and  JOIN 
and  LEAVE . 


The  class  of  Intercommunication  Data  Area  providing  unidirectional  data 
flow  between  Activities. 


The  Timing  Primitive  which  allows  an  Activity  to  delay  further 
processing  until  a time,  specified  as  a parameter  in  the  call,  has 
elapsed. 


The  construction  function  that  removes  a sub-system. 


The  Termination  Primitive  which  enables  an  Activity  to  terminate  itself 
correctly. 


The  Monitor  function  to  remove  a function.  Activity  or  Control  Queue 
from  being  Monitored. 


The  construction  function  used  to  build  MASCOT  Sub-systems  from  System 
Elements. 


A term  used  to  describe  the  facilities  provided  in  MASCOT  for  sub-system 
control  and  monitoring.  A function  is  available  for  use  by  Activities 
via  a procedural  interface. 


A routine  which  responds  directly  to  an  interrupt. 


The  sub-system  control  function  which  stops  a sub-system  but  allows  a 
subsequent  restart.  See  also  RESUME. 


The  means  by  which  Activities  interact.  May  be  one  of  two  types, 
Channel  or  Pool. 


The  Monitor  function  to  switch  recording  on  or  off. 


The  Synchronisation  Primitive  which  allows  an  Activity  to  gain  exclusive 
access  to  a Control  Queue. 


That  part  of  a MASCOT  system  which  provides  the  chosen  scheduling, 
interrupt  handling,  sub-system  control  and  monitoring  facilities. 


The  Synchronisation  Primitive  which  allows  an  Activity  to  release  its 
hold  on  a Control  Queue. 


The  construction  function  used  to  create  a System  Element. 


A Kernel  facility  which  provides  a means  of  observing  and  recording  the 
interactions  between  sub-systems  and  the  kernel. 


The  Monitor  function  to  switch  processing  of  recorded  data  on  and  off. 


The  Intercommunication  Data  Area  providing  storage  of  data  which  may 
be  read  or  modified  by  a number  of  Activities. 


An  indivisible  operation  within  the  Kernel. 
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NAME 

RECORD 

RESET 

RESUME 

Root  Procedure 

SELECT 


Slice 


DESCRIPTION 

The  Data  Recording  Primitive  which  enables  Activities  to  present  data 
to  the  Monitor. 

The  Monitor  function  to  return  the  Monitor  to  its  initial  state. 

The  Sub-system  Control  function  to  continue  the  operation  of  a 
Sub-system  from  the  point  where  it  was  stopped  (see  also  HALT). 

The  program  which  defines  the  operation  of  an  Activity.  The  formal 
parameters  of  the  Root  Procedure  define  the  number  and  type  of  the 
IDAs  which  the  Activity  will  be  able  to  access.  It  may  also  have  value 
parameters. 

The  monitor  function  which  adds  a function.  Activity  or  Control  Queue 
to  the  Monitored  subset. 

A period  of  execution  of  an  Activity  terminated  by  an  interrupt  or  a 
return  to  the  scheduler. 


START 

STIM 

Sub-system 

SUSPEND 

System  Elements 

TERMINATE 

TIMENOW 

UNLOAD 

WAIT 


The  Sub-system  Control  function  which  starts  a Sub-system. 

The  Synchronisation  Primitive  operation  by  which  an  Activity  can  apply 
a software  stimulus  to  a Control  Queue. 

The  major  unit  of  construction  and  control  in  a MASCOT  system.  It  is 
created  from  System  Elements  by  the  FORM  command. 

The  Co-operative  Scheduling  Primitive  by  which  an  Activity  can 
unconditionally  return  control  to  the  scheduler. 

The  Root  Procedures,  Channels  and  Pools  which  are  used  by  the  FORM 
command  to  construct  Sub-systems. 

The  Sub-system  Control  function  which  closes  down  all  Activities  within 
a Sub-system. 

The  Timing  Primitive  which  delivers  the  value  of  time  used  in  delay 
measurement. 

The  construction  function  used  to  remove  a System  Element. 

The  Synchronisation  Primitive  operation  which  allows  an  Activity  to 
wait  for  a software  stimulus  on  a specified  Control  Queue. 
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Fig.  1 Summary  of  MASCOT  facilities  and  functions 
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Fig.2  An  ACP  diagram 
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Fig.3  Concepts  in  hardware 
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Fig.4  MOD  bus  system 
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DISCUSSION 


R.N. Oldfield 

Although  every  manufacturer  is  extremely  unhappy  if  he  is  forced  to  use  someone  elses  standards  and  approach, 
it  is  a situation  which  has  worked  well  in  some  areas  and  may  become  a more  frequent  occurrence  (e.g.  consideration 
of  PDP-1 1 by  DoD).  Would  not  such  an  approach  have  significant  advantages  to  the  military  in  that  it  would  increase 
the  likelihood  of  continued  support,  rather  than  the  use  of  a compromise  standard  in  which  no  one  manufacturer  has 
a real  commercial  stake? 

Authors’  Reply 

While  this  approach  would  have  made  life  simpler  for  us  in  the  short  run,  we  believe  this  would  not  have  been  the 
way  to  achieve  our  aim  of  obtaining  widespread  support  in  industry.  We  also  reserve  the  right  to  have  multi-source 
supply  possibilities  by  our  current  approach.  This  probably  would  not  have  been  possible  if  we  had  chosen  a 
manufacturer’s  own  standard.  If  we  are  correct  in  our  assessment  of  future  requirements  then  the  proposed 
proponents  will  have  commercial  possibilities. 


J. Shepherd 

Are  we  really  going  to  get  a standard  system  which  will  last  20  years  or  will  it  be  overtaken  by  microprocessor 
architecture  developments? 

Authors’  Reply 

The  intention  in  partitioning  the  system  into  major  functional  elements  i.e.,  processors,  32K  store,  peripherals,  etc. 
is  that  this  will  not  be  the  case.  Providing  such  units  remain  plug  compatible  and  thus  are  capable  of  meeting  the 
new  communications  requirements  then  we  will  achieve  our  aim  of  technological  independence. 


J. Shepherd 

If  MASCOT  is  as  good  as  is  claimed  then  why  do  the  software  houses  not  use  it? 

Authors’  Reply 

If  it  is  true  that  software  houses  do  not  use  MASCOT  then  it  is  due  to  the  difference  between  the  commercial 
requirements  of  software  and  the  military  requirements. 


F.  A.  Os  tern 

What  kind  of  ruggedizing  have  you  recommended  for  the  double  European  cards  to  fulfil  the  environmental 
specifications,  especially  concerning  vibration  and  shock? 


Authors’  Reply 

The  cards  will  meet  the  normal  Naval  specifications. 


R.N.Oldfield  , 

As  a complete  hardware  and  software  package,  the  standards  are  unique  and  do  not  relate  directly  to  a complete 
commercially  available  package.  Other  speakers  have  suggested  that  military  efforts  in  this  field  will  only  succeed 
if  they  are  taken  up  by  the  commercial  field.  Do  you  believe  this  will  occur,  and  what  are  the  implications  ot 
failure  and  of  the  commercial  field  to  take  up  the  standards  with  real  enthusiasm? 


Authors’  Reply 

We  believe  that  where  possible  we  have  chosen  commercially  available  packages.  Where  we  have  not  done  so  e.g. 
interface  mod  bus,  MASCOT  and  LORAC  66  this  was  because  no  neutral  commercial  alternative  was  available. 
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ABSTRACT 


From  a logistics  or  maintenance  viewpoint,  NO  changes  should  be  permitted  in  the 
computer  programs  used  to  control  operational  weapon  systems.  From  the  viewpoint 
of  effectiveness  or  performance,  it  is  often  NECESSARY  to  change  the  computers  embedded 
in  operational  weapon  systems,  to  react  to  a new  threat,  to  counter  a new  enemy  tactic 
or  capability,  or  to  support  the  needs  of  an  associated  new  weapon  system  whose  require- 
ments for  input  data  quality  are  more  demanding.  As  a result,  it  is  common  for  the 
software  for  embedded  computers  to  be  subjected  to  regular  change,  despite  the  associated 
logistic  problems.  Therefore,  it  is  important  to  develop  software  design  techniques 
which  minimize  the  cost  impacts  of  software  changes. 

At  SINGER-Kearfott  we  addressed  this  issue  for  our  guidance,  navigation  and 
communication  products  by  turning  to  the  modern  structured  software  design  methodologies 
which  stress  simplicity  of  form,  readability  of  code,  and  hierarchical  organization. 

While  achieving  some  success,  the  cost  of  program  changes  was  still  unsatisfactorily 
high.  We  then  turned  to  a technique  originated  by  D.  L.  Parnas  for  partitioning 
computer  programs  to  facilitate  future  changes. 

This  technique  has  been  used  on  a number  of  Kearfott  avionics  systems  (e.a.,  the 
AN/URQ-28  communications  terminal  for  JTIDS)  with  significant  success.  There  are 
numerous  examples  of  small  program  changes  accomplished  at  negligible  cost  and  substantial 
program  changes  whose  cost  was  very  modest.  This  paper  reviews  the  Parnas  Partitioning 
technique  and  its  application  to  avionic  software  by  the  use  of  pertinent  examples.  The 
most  successful  use  of  the  technique  for  weapon  systems  requires  participation  by  the 
software  design  engineer,  the  systems  design  engineer,  the  customer's  project  engineer, 
and  the  end  user.  The  role  of  each  of  these  participants  is  identified. 


1.  BACKGROUND 

The  use  of  digital  control  for  new  avionics  systems  is  now  essentially  universal. 

One  reason  for  this  dominance  is  the  substantial  increase  in  flexibility  which  digital 
control  systems  provide  in  comparison  to  analog  systems.  The  digital  system  designer 
often  tries  to  maximize  this  flexibility  by  designing  systems  whose  control  functions 
are  defined  in  memory  devices  which  can  either  be  easily  replaced  or  whose  contents  are 
easily  changed.  Since  this  design  approach  makes  it  easy  to  replace  one  control 
program  by  another,  it  would  appear  that  the  flexibility  of  these  systems  is  assured. 
Changes  in  the  control  system  are  usually  reduced  to  being  "simply  software  changes". 
(Incidentally,  in  this  paper  we  shall  use  the  term  software  to  refer  to  any  program, 
even  if  it  is  stored  as  "firmware"  in  ROM  memory.) 

However,  we  soon  find  that  it  is  not  so  easy  to  develop  the  software  design  change 
required  to  implement  a particular  control  system  change,  especially  for  large,  complex 
software  systems.  This  problem  is  often  referred  to  as  the  Software  Maintenance  Problem 
and  it  is  now  well  known  that  much  more  money  is  spent  by  the  DOD  on  software  maintenance 
than  on  software  development.  Have  we  then  deluded  ourselves  on  the  flexibility  of 
digital  systems?  Have  we  merely  traded  a hardware  change  problem  for  a software 
change  problem? 

Of  course  this  is  not  true.  Even  with  the  substantial  expenditures  required  to 
maintain  control  system  software,  the  implementation  of  design  changes  of  similar  scope 
in  analog  systems  would  be  dramatically  more  expensive.  In  fact  the  changes  themselves 
would  often  not  be  undertaken  due  to  their  prohibitive  expense.  So  we  agree  that  the 
flexibility  of  digital  systems  is  hot  illusory,  however,  this  flexibility  is  severely 
limited  by  the  Software  Maintenance  Problem.  In  fact,  our  intuition  tells  us  that  we 
should  be  able  to  develop  technical  and  managerial  approaches  to  dramatically  reduce 
the  Software  Maintenance  Problem  thus  improving  the  flexibility  of  the  systems  which 
they  control.  This  paper  is  devoted  to  the  identification  of  one  such  technique  which 
has  been  successfully  used  by  the  Kearfott  Division  of  The  Singer  Company  to  develop 
flexible  avionic  software.  Since  the  technique  is  as  much  managerial  as  it  is  technical, 
it  promises  to  have  value  for  all  types  of  software.  In  fact  it  should  prove  useful 
in  the  design  of  more  general  systems  as  well. 

Before  pressing  on  with  the  exposition  of  this  approach,  we  should  consider  the 
question:  Is  this  search  for  design  flexibility  NECESSARY,  or  are  we  merely  succumbing 

to  the  engineer's  tendency  to  continuously  refine  his  design,  beyond  the  point  where 
any  useful  gain  is  obtained  in  system  performance?  There  is  no  universal  answer  to 
this  question.  Certainly  in  some  cases  the  persistent  changing  in  system  software 
is  excessive.  Some  changes  do  not  make  a system  truly  "better",  rather  they  merely 
make  them  "different".  However,  the  new  flexibilitv  provided  by  digital  systems  has 
prompted  the  design  of  systems  which  depend  in  a crucial  manner  on  the  ability  to  make 
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rapid  implementation  changes.  For  example,  digitally  controlled  ECM  systems  are  now 
developed  which  depend  for  their  success  on  current  knowledge  of  an  adversary’s 
radiation  habits.  When  he  changes  his  radiation  habits  (say  by  the  introduction  of  a 
new  weapon),  we  MOST  change  the  control  of  the  ECM  system  accordingly.  Consequently, 
anything  which  limits  our  ability  to  change  this  ECM  system  rapidly  and  efficiently, 
serves  as  a limit  on  the  system's  ability  to  respond  to  a new  threat  or  strategy.  It 
is  therefore  important  for  us  to  find  solutions  to  the  Software  Maintenance  Problem. 

2.  INTRODUCTION 

The  desirability  of  designing  modular  programs  appears  to  be  one  of  the  axioms  of 
computer  software  engineering.  It  is  neither  proven  nor  questioned.  Programmers  have 
been  trying  to  build  modular  programs  for  almost  two  decades.  But  what  is  meant  by  a 
modular  program  and  what  is  a module?  Let's  consider  the  following  candidate  definition: 

A program  is  modular  if  it  is  decomposed  into  a number  of  small  manageable  modules. 

While  we  could  probably  get  near  universal  agreement  on  the  validity  of  this  statement, 
it  does  nothing  to  clarify  the  meaning  of  the  phrase  "manageable  module".  A search  of 
the  literature  will  reveal  that  many  guidelines  have  been  proposed  for  use  in  defining 
a manageable  module.  Several  of  these  are  listed  below: 

o Modules  must  be  independent  of  each  other. 

o A module  implements  an  indivisible  function. 

o A module  should  have  only  one  entrance  and  exit. 

o A module  does  not  affect  parameters  other  than  its  formal  arguments, 
o The  function  of  a module  is  unaffected  by: 

"the  source  of  its  input 

"the  destination  of  its  output 

"the  past  history  of  the  module. 

o Modules  must  be  small,  i.e., 

less  than  100  statements,  or 

I less  than  10  decision  statements,  or 

one  page  of  source  code,  or 
one  page  of  flowchart,  etc. 

o Modules  must  be  separately  compiled, 
o Modules  should  have  uniform  work  content 
‘ e.g. , each  requires  one  manmonth  to  develop, 

o Modules  must  be  separately  testable. 

It  would  certainly  be  very  useful  if  we  could  show  that  one  or  more  of  these  definitions 
of  a manageable  module  were  sufficient  to  guarantee  the  flexibility  of  the  resulting 
program  product.  Unfortunately,  experience  has  shown  that  many  programs,  which  are 
highly  modular  by  one  or  more  of  the  above  guidelines,  exhibit  unsatisfactory  performance 
characteristics.  In  particular,  these  definitions  of  modularity  do  NOT  appear  to  be 
the  answer  to  assuring  flexibility  in  program  design.  This  is  not  to  say  that  the  above 
precepts  do  not  have  beneficial  effects  on  program  design  but  that  there  are  many 
examples  of  good,  modular  programs  (by  the  above  criteria)  that  are  still  difficult 
and  expensive  to  change.  What  are  we  missing?  Could  the  unsatisfactory  performance  of 
our  "modular"  programs  be  traced  to  a weakness  in  our  definition  of  modularity? 


3.  THE  PARNAS  APPROACH 

According  to  a paper  by  D.  L.  Parnas  in  1972  (1) , we  are  indeed  missing  a central 
ingredient  in  our  definition  of  modularity.  He  illustrates  this  weakness  through  the 
medium  of  a very  simple  example,  a program  to  generate  a KWIC  (Key  Word  in  Context)  index 
from  a set  of  input  word  strings  representing  titles  of  books  or  papers  (for  example). 

A KWIC  index  is  a listing  of  all  rotations  of  the  words  in  the  title.  As  an  illustration 
of  this  process,  consider  the  titles  of  the  papers  presented  at  the  previous  session 
at  this  Conference  on  Tactical  Data  Processing  Hardware  (see  Figure  1).  Each  paper 
title  is  provided  to  the  KWIC  Index  program  as  a character  string  input.  The  program 
must  generate  all  possible  rotations  of  each  title  (see  Figure  2).  Then  the  program 
must  print  all  the  rotated  titles  in  alphabetic  order  (see  Figure  3) . 

Let  us  now  design  a modular  program  to  perform  this  function.  We  can  begin  by 
partitioning  the  program  into  a set  of  modules  consistent  with  ALL  the  modularity 
criteria  presented  in  the  previous  section.  One  obvious  candidate  for  such  a parti- 
tioning results  in  modules  for  each  of  the  following  functions: 
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o Input  of  word  strings  representing  titles 
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o Rotation  (circular  shift)  of  word  strings 
o Alphabetizing  the  rotated  word  strings 
o Output  of  KWIC  index 
o Master  control 

With  a module  to  perform  each  of  these  functions,  we  have  a partitioning  of  the 

problem  that  satisfies  all  the  above  guidelines  for  good  module  design.  Figures  4 and  5 

depict  the  control  flow  of  this  modular  program  and  the  invocation  hierarchy  respectively. 

The  key  question  now  is  whether  this  modularization  or  partitioning  of  the  problem 
will  result  in  an  easily  maintainable  program.  That  is,  can  we  expect  to  be  able  to 
easily  modify  this  program  to  accommodate  future  changes  in  requirements?  To  answer 
this  question,  we  shall  consider  the  impact  on  the  program  of  certain  expected  design 
changes.  But  first  we  must  develop  some  additional  design  detail  about  each  of 
these  modules. 

The  Input  Module  is  responsible  for  reading  the  input  lines  of  text  from  the 
input  medium.  The  input  is  a character  string  with  blanks  to  delimit  the  words. 

These  lines  are  then  placed  in  common  memory  for  use  by  other  modules,  using  the 
following  design  details: 

o Characters  are  packed,  4 to  a memory  word. 

o An  index  is  formed  to  show  starting  address  of  each  line. 

o A special  character  (*)  is  inserted  to  designate  end  of  line. 

The  Rotation  Module  scans  each  line  placed  in  memory  by  the  Input  Module.  It 
creates  an  index  to  the  first  word  in  each  rotated  version  of  a line.  This  table  of 
indices  requires  much  less  memory  than  if  each  rotated  line  were  replicated  in  memory. 

The  Alphabetizing  Module  generates  a table  of  indices  to  the  first  word  in  each 
rotated  line  such  that  the  entries  in  the  table  are  in  alphabetical  order.  This  is 
achieved  by  scanning  the  table  of  indices  provided  by  the  Rotation  Module  in  conjunction 
with  the  representation  of  the  line  stored  in  memory.  A new  table  of  indices  is  then 
constructed  whose  entries  are  in  alphabetical  order. 

The  Output  Module  prints  each  rotated  line  in  alphabetical  order.  This  is 
achieved  by  processing  each  index  in  the  table  provided  by  the  Alphabetizing  Module 
in  their  order  of  occurrence.  The  index  is  used  as  a pointer  to  fetch  the  desired 
line  from  common  memory  for  printing  in  the  desired  format. 

The  Master  Control  Module  is  little  more  than  a traffic  cop.  It  performs  the 
following  functions: 

o Controls  sequencing  among  other  modules, 
o Handles  error  returns  from  modules, 
o Generates  error  messages, 
o Handles  space  allocation. 

Now  we  are  ready  to  determine  whether  this  modularization  is  easily  adaptable 
to  change  in  design  decisions.  If  so,  it  would  indicate  an  easily  maintainable  product. 

If  not,  we  would  be  forced  to  conclude  that  our  partitioning  of  the  problem  did  not 
achieve  its  primary  purpose  and  would  have  to  search  for  a superior  modularization. 

Toward  that  end,  let's  consider  the  following  candidates  changes  in  the  system  design: 

1)  Revise  the  format  of  the  input  word  strings.  For  example, 
the  designation  for  end  of  line  might  be  changed. 

2)  Change  the  output  format.  For  example,  instead  of  printing 
the  alphabetized  lead  word  of  a rotated  line  left-adjusted 
on  the  page,  we  might  print  the  alphabetized  lead  word  in 
the  center  of  the  page,  with  the  other  words  in  the  line 
printed  in  their  original  order  to  the  left  and  right  of 
the  lead  word. 


3)  To  increase  the  portabilitv  of  the  system  between  computers 
of  different  word  size,  we  might  change  from  packing  four  (4) 
characters  per  memory  word  to  packing  one  (1)  character  per 
memory  word.  We  thereby  increase  portability  at  the  expense 
of  memory  efficiency. 

4)  To  expand  the  system  to  handle  very  large  input  files,  we 
might  war  t to  store  the  word  strings  on  disc  rather  than 
in  main  memory. 

What  impact  do  these  proposed  changes  have  on  our  program? 
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The  first  two  changes  are  easily  handled,  since  they  each  impact  a single  module, 
with  NO  impact  on  other  modules  in  the  system.  Change  #1  can  be  entirely  handled  in 
the  Input  Module  and  Change  #2  can  be  entirel  • handled  in  the  Output  Module.  So  with 
respect  to  these  changes,  our  modularization  is  very  effective  and  the  program  appears 
to  be  very  easy  to  maintain. 

However,  the  results  are  not  so  good  for  Changes  #3  and  #4.  Each  of  them  affect 
FOUR  program  modules!  Only  one  module  (Master  Control)  is  unaffected  by  these  changes. 
The  root  of  the  problem  is  the  fact  that  all  four  modules  directly  access  the  lines 
stored  in  main  memory.  So  a change  in  the  format  used  to  store  these  lines  must  be 
accommodated  by  all  four  modules.  Therefore,  if  these  changes  are  likely  to  occur, 
this  modularization  will  not  result  in  a program  which  is  easy  to  maintain,  i.e., 
to  change. 

Can  we  amend  our  design  to  better  accommodate  Change  #3  and  #4?  Ideally,  we 
would  like  the  effect  of  each  change  to  be  localized  to  a single  module.  Parnas 1 
suggestion  is  to  make  an  explicit  list  of  design  assumptions  or  characteristics  which 
are  likely  to  change  in  future  versions  of  the  system.  Then  when  you  pr  tition  the 
problem  to  form  your  program  modules,  select  a partitioning  which  suer  s in  hiding 
each  design  assumption  in  as  small  a portion  of  the  program  as  possiv  The  design 

assumption  might  be  hidden  in  a single  statement  (if  possible) , or  i ngle  module 

or  in  a minimum  number  of  modules.  Then,  if  future  changes  are  of  t ae  indicated 

in  your  list  of  changeable  design  assumptions,  you  can  be  assured  th  air  impact 

is  highly  localized.  You  can  confidently  expect  that  a localized  desi._,  change  can 
be  much  more  easily  implemented  than  if  its  impact  were  to  spread  over  many  modules. 

A corollary  of  this  approach  is  the  realization  that  if  you  do  not  know  the  nature 
of  probable  future  changes  to  your  system,  you  are  likely  to  be  unsuccessful  in 
selecting  a problem  partitioning  which  will  localize  the  impact  of  these  changes. 

To  illustrate  the  power  of  this  approach,  let's  return  to  the  KWIC  Index  Program, 
realizing  that  one  of  our  changeable  design  assumptions  is  the  specific  format  and 
organization  of  the  line  storage  activity  within  the  computer  (since  both  Change  #3 
and  #4  are  of  this  type).  The  next  step  is  obvious.  Construct  a Line  Storage  Module 
which  handles  all  access  to  lines  in  memory.  It  would  naturally  hide  all  assumptions 
on  line  format  from  the  other  four  modules,  which  would  have  to  call  it.  The  basic 
functions  of  the  Line  Storage  Module  are  listed  below: 

o Provides  total  interface  with  lines  of  text  stored  in  memory. 

o Interfaces  with  other  modules  on  a character  basis. 

o Uses  index  to  reference  characters  in  text. 

o Performs  several  line-access  functions. 

Figure  6 shows  the  revised  invocation  hierarchy  chart.  Note  that  the  control  flowchart 
does  not  change,  which  indicates  that  the  control  flow  will  not  usually  be  a clear 
indicator  of  the  modularization  which  facilitates  future  change. 

As  a result  of  adding  the  Line  Storage  Module  to  our  partitioning  of  the  KWIC 
Index  problem,  we  appear  to  have  created  a design  which  is  easily  adapted  to  handle  the 
type  of  changes  envisioned.  However,  it  is  important  to  realize  that  this  flexibility 
has  been  achieved  at  the  cost  of  program  efficiency.  The  need  to  use  the  Line  Storage 
Module  for  all  line  access  will  probably  have  a detrimental  effect  on  the  size  and 
speed  of  the  overall  program.  But  this  increased  cost  may  be  worthwhile  if  in  fact 
the  anticipated  changes  are  eventually  implemented.  If  the  anticipated  changes  are  not 
eventually  implemented,  we  will  have  decreased  the  efficiency  of  the  program  to  no 
purpose.  It  follows,  then,  that  the  list  of  design  assumptions  used  to  select  the 
partitioning  of  the  problem  must  be  carefully  selected.  It  is  not  sufficient  that 
one  can  conceive  of  changing  a design  assumption,  the  likelihood  of  that  change  must 
be  high  for  it  to  be  included  in  what  we  have  come  to  refer  to  as  the  Hiding  Assumption 
List.  If  the  entries  in  this  list  are  capriciously  selected,  we  can  expect  inefficiency 
in  the  resulting  program  product.  In  short,  the  decision  to  add  the  Line  Storage  Module 
to  the  KWIC  Index  program  must  be  considered  a poor  design  decision  if  changes  in  line 
format  are  NOT  likely  to  occur. 

In  stammary,  then,  the  Parnas  approach  requires  that  you  build  a list  of  changeable 
design  assumptions  whose  impact  you  wish  to  hide  from  as  much  of  the  program  as  possible. 
We've  come  to  refer  to  this  as  the  Hiding  Assumption  List.  The  program  is  then  designed 
to  localize  the  impact  of  each  change  represented  on  the  list. 


4.  PARNAS  PARTITIONING  IN  AVIONICS  SOFTWARE 

At  Singer- Rear fott  we  develop  software  for  computers  embedded  in  our  GN&C  systems. 
Our  primary  motivation  in  developing  these  programs  is  to  avoid  the  need  for  future 
change  (pursued  via  careful  specification  and  exhaustive  checkout) . This  is  especially 
true  for  our  general  purpose  products  such  as  the  AN/ASN-128  Doppler  Navigation  System 
and  our  Standard  Inertial  Navigation  System.  Since  this  Utopia  is  very  difficult  to 
achieve,  our  next  line  of  defense  is  to  minimize  the  impact  of  future  changes.  Since 
many  of  our  navigation  systems  have  the  control  program  implemented  in  Read  Only 
Memory  (ROM) , this  provides  another  motivation  to  localize  the  impact  of  design  changes 
to  a few  ROM  devices,  thus  protecting  our  investment  in  the  remainder  of  the  ROM  memory. 
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Prior  to  our  decision  to  use  the  explicit  Hiding  Assumption  List  proposed  by 
Parnas , we  carefully  modularized  our  avionic  programs  by  the  prior  criteria  for  proper 
modularization.  We  also  employed  many  of  the  precepts  of  structured  programming  and 
top-down  design.  Although  there  were  beneficial  effects  on  program  development  cost, 
readability  of  code,  etc. , we  were  still  plagued  by  the  high  cost  and  schedule  impact 
of  program  changes.  Upon  reading  the  paper  by  Parnas  (1),  it  became  clear  that  we 
could  NEVER  expect  to  develop  a program  modul. rization  to  successfully  handle  a change 
we  were  unaware  of.  That  is,  the  suggestion  seemed  eminently  reasonable  that  successful 
partitioning  of  the  problem  could  only  be  assured  if  you  developed  an  EXPLICIT  list 
of  expected  design  changes  and  used  their  localization  as  a criteria  for  selecting 
the  problem  partitioning.  This  technique,  which  we  came  to  refer  to  as  Parnas  Parti- 
tioning, we  then  began  to  use  for  our  avionics  software  development.  At  first  it  was 
used  on  small  systems  with  substantial  success.  Then  we  began  to  use  it  even  for  our 
larger  systems,  with  a continuing  record  of  success.  In  this  paper  we  shall  illustrate 
the  use  of  the  method  on  our  Joint  Tactical  Information  Distribution  System  (JTIDS) . 

To  set  the  stage  for  our  discussion,  a few  words  are  in  order  on  the  nature  of 
the  JTIDS  concept.  It  is  a form  of  digital  radio  which  enables  cooperating  users 
equipped  with  JTIDS  terminals  to  communicate  with  each  other  and  to  perform  precision 
local  navigation.  It  is  based  on  using  digitized  electromagnetic  radiation  for  two 
purposes,  viz.: 

1)  Transmit  secure  information  among  cooperating  users  based 
on  a complicated  modulation  and  encoding  of  the  waveform. 

2)  Compute  range  between  any  two  cooperating  users  by 
measuring  the  time  required  for  an  interrogating  pulse 
to  be  returned. 

The  resulting  system  provides  an  unprecedented  communication  and  navigation  capability 
within  a single  system. 

Singer-Kearfott  has  been  engaged  in  the  development  of  the  JTIDS  concepts  from 
their  inception.  Most  recently,  Kearfott  developed  the  AN/URQ-28  JTIDS  Terminal  for 
Class  2 applications,  i.e.,  tactical  aircraft.  This  terminal  provides:  , 

o Secure  communication  within  community  using  digital  TDMA  techniques. 

o Distance  measurement  using  RF  ranging  to  cooperative  members. 

o Accurate  relative  navigation  via  Kalman  mixing  of  all  navigation  data. 

o Integral  TACAN  navigation  system,  sharing  TDMA  RF  receiver. 

The  TDMA  (Time  Division  Multiple  Access)  facility  is  based  on  dividing  time  into  7.8 
millisecond  intervals  (slots)  and  synchronizing  all  users  to  this  slot  structure. 

Each  slot  is  assigned  for  a particular  purpose,  using  a common  slot  assignment  algorithm 
throughout  the  community.  Control  of  the  Class  2 terminal  is  handled  by  an  embedded 
computer,  one  of  our  SKC3120  family  of  computers.  The  embedded  computer  employs  a 
mixture  of  RAM,  ROM,  and  EROM  as  its  main  memory.  The  functions  implemented  in  the 
control  software  are  outlined  in  the  accompanying  top-level  function  chart  (Figure  7) . 
Since  this  collection  of  communication  and  navigation  functions  had  never  before  been 
implemented  as  a single  program  and  since  the  scope  of  the  message  communication 
function  was  greater  than  all  the  predecessor  systems,  it  was  obviously  likely  that 
significant  changes  would  be  required  during  the  lifetime  of  this  system.  Our  challenge 
was  to  implement  the  software  in  a manner  which  would  facilitate  later  change. 

The  Parnas  Partitioning  concept  seemed  ideally  suited  for  use  in  this  application. 
Moreover,  our  contract  called  for  the  implementation  of  a "modular  program"  so  we  were 
quick  to  seize  on  the  Assumption  Hiding  List  as  not  only  a design  tool  but  also  to 
serve  as  a means  of  communications  with  our  customer  on  the  modularity  decisions  as 
they  were  being  made.  Since  the  concept  was  new  to  project  personnel  outside  the 
Computer  Software  Department,  the  first  version  of  the  Hiding  Assumption  List  was 
prepared  by  Software  Engineers,  taking  as  broad  a systems  view  as  possible.  The  list 
was  then  supplied  to  Systems  Analysts  to  solicit  their  participation  in  refining  its 
content.  Following  this,  the  list  was  successively  provided  to  Systems  Engineers, 
Technical  Management,  and  Program  Management  within  Kearfott  and  then  to  our  customer 
representatives.  This  broad  participation  was  sought  since  the  list  can  contain 
assumptions  from  all  levels,  including:  system  requirements,  system  design,  and  software 
design.  At  each  level,  useful  comments  were  received  and  participation  was  enthusiastic. 
Since  the  design  assumptions  were  usually  top  level  concepts,  they  could  be  expressed 
in  language  understandable  by  everyone  in  this  refinement  sequence.  We  now  believe 
that  this  is  one  of  the  major  advantages  of  the  Parnas  Partitioning  approach.  It 
does  not  require  knowledge  of  Computer  Science  in  general  or  even  knowledge  of  the  design 
details  of  the  program  in  question,  for  someone  to  participate  in  constructing  the  Hiding 
Assumption  List.  All  that  is  required  is  the  ability  to  predict  which  features  of  the 
system  design  are  likely  to  change  in  the  future.  This  of  course  requires  knowledge 
of  the  system  design  and  its  ultimate  application,  but  not  of  software  design.  For 
operational  systems,  we  even  suggest  that  the  list  of  participants  in  constructing 
the  Hiding  Assumption  List  be  expanded  to  include  the  end  user  of  the  system.  In 
this  fashion  he  can  supply  his  concept  of  system  flexibility  DIRECTLY  to  the  software 
designer  in  a manner  that  is  both  directly  usable  in  software  design  and  easily 


reviewed  by  all  other  involved  parties.  In  short,  we  feel  that  one  major  advantage 
of  the  Hiding  Assumption  List  is  its  ability  to  be  used  for  communication  by  ALL 
personnel  involved  vn  establishing  system  requirements  or  system  design,  since  it 
is  written  in  plain  English. 

As  a result  of  this  extensive  refinement  process,  a large  Hiding  Assumption  List 
was  generated  for  the  software  to  be  designed  for  the  JTIDS  Class  2 Terminal.  To 
illustrate  the  typical  content  of  such  a list,  a portion  of  the  JTIDS  Hiding  Assumption 
List  is  presented  below: 

o The  format,  content,  and  priority  of  JTIDS  messages. 

o The  characteristics  of  external  dead  reckoning  navigation 
system  (cycle  rate,  scaling,  format,  accuracy,  etc.). 

o The  criteria  for  message  screening  and  routing. 

o The  number  of  slot  sequences  used  during  coarse  synchronization. 

o The  criteria  for  generation  of  range  interrogation. 

o Algorithm  for  selecting  member  for  ranging. 

o Format  of  TACAN  output:  Range  & Bearing. 

o Number  of  dynamic  states  in  relative  navigation  filter. 

o Relative  navigation  observation  logic:  number  processed, 
selection  logic,  validity  criteria,  etc. 

o Format  of  message  at  I/O  ports. 

These  assumptions  and  the  many  others  contained  in  the  full  list  were  then  used  as  a 
primary  criteria  for  partitioning  the  software  design.  In  many  cases,  the  desired 
flexibility  could  be  achieved  by  selecting  a design  alternative  with  no  attendant 
degradation  in  software  efficiency.  The  desire  to  hide  a design  assumption  in  a 
single  module  occasionally  proved  very  difficult.  In  these  cases  a determination 
had  to  be  made  on  the  proper  compromise  between  program  efficiency  on  the  one  hand 
and  program  flexibility  on  the  other. 

The  software  design  which  resulted  from  this  use  of  the  Assumption  Hiding  List 
has  already  shown  signs  of  being  very  flexible  and  adaptable.  During  initial  integration 
of  this  software  with  the  new  terminal  hardware,  confusion  arose  as  to  the  specific 
signals  required  for  Input/Output  operations  (as  often  happens  in  new  systems)  . In 
this  case,  however,  the  logic  for  each  interface  had  been  implemented  in  a macro  which 
was  invoked  at  several  points  in  the  program.  The  signal  confusion  was  readily 
resolved  (i.e.,  within  a couple  of  hours)  by  changing  a couple  of  lines  of  code  in 
the  macro  definition.  A reassembly  then  produced  a corrected  program  ready  for  further 
integration  testing.  Much  later  in  the  development  cycle,  the  customer  developed  an 
improved  standard  for  message  formats.  This  change  is  now  being  incorporated  in  the 
delivered  program.  Thanks  to  the  first  item  in  the  Hiding  Assumption  List,  this 
change  is  confined  to  the  few  modules  which  were  permitted  to  be  dependent  upon  the 
message  catalog  format.  If  the  Hiding  Assumption  List  were  not  used  as  an  explicit 
criteria  for  partitioning  the  problem  into  modules,  it  is  easy  to  envision  the  need 
for  a much  more  revolutionary  change  to  the  program  with  almost  all  modules  affected. 

The  use  of  Parnas  Partitioning  thus  cut  down  the  effect  of  this  change  to  very 
manageable  proportions. 

However,  it  should  also  be  stated  that  these  early  attempts  to  use  Parnas 
Partitioning  were  not  100%  successful.  Although  the  good  examples  mentioned  above 
are  reasonably  typical  of  our  experience  on  all  projects,  there  were  also  some  cases 
where  the  requested  change  was  not  localized  and  the  effort  required  for  its  imple- 
mentation was  not  trivial.  There  appeared  to  be  two  primary  causes  for  these  problems: 

1)  The  type  of  change  was  NOT  listed  in  the  Hiding  Assumption 
List,  so  the  design  activity  did  not  attempt  to  localize 
its  impact. 

2)  The  actual  implementation  had  wandered  from  the  intent  of 
the  original  partitioning  decision  due  to  laxity  in 
enforcement  of  the  isolation  decisions. 

While  it  is  always  more  pleasant  to  achieve  100%  success,  there  must  be  significant 
solace  in  the  realization  that  the  two  problems  listed  above  are  not  weaknesses  in 
the  Parnas  Partitioning  approach,  but  in  the  way  it  was  conducted.  Therefore  it 
should  be  possible  to  eliminate  them  in  future  systems  by  aggressive  management  action. 
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5.  OTHER  ASPECTS  OF  PARNAS  PARTITIONING 


The  apparent  simplicity  of  the  Parnas  Partitioning  concept  belies  its  profound 
effect  on  the  design  of  a complex  software  system.  Like  many  good  ideas,  its  beauty 
is  in  its  simplicity.  It  is  this  simplicity  which  assures  its  success  as  a medium 
for  communication  between  the  diverse  disciplines  involved  in  developing  the  modern 
avionic  system.  Since  the  items  in  the  Hiding  Assumption  List  used  for  Parnas 
Partitioning  are  expressed  directly  in  English,  contributions  to  the  list  may  be 
obtained  from:  Software  Engineers,  System  Analysts,  System  Engineers,  Technical 
Management,  Program  Management,  customer  representative,  and  even  the  end  user  of 
the  system.  In  short,  anyone  who  can  initiate  a change  in  the  system  can  contribute 
to  the  Hiding  Assumption  List.  By  canvassing  all  these  contributors,  we  would  hope 
that  the  resulting  List  would  be  complete,  that  is,  no  changes  with  significant 
probability  of  occurrence  are  omitted.  As  we  saw  in  the  previous  section,  the  omission 
of  a probable  change  from  the  List  can  make  the  modularity  decision  ineffective,  since 
the  resulting  system  design  is  vulnerable  to  the  omitted  change.  So  we  see  that  the 
List  can  be  too  short.  However,  the  list  can  also  be  too  long.  If  it  is  expanded  to 
include  all  changes  which  the  contributors  can  think  of,  the  buildup  of  inefficiency  in 
the  resulting  program  may  become  intolerable. 

So  we  are  faced  with  the  dilemma  of  a Hiding  Assumption  List  that  is  either  too 
long  or  too  short.  How  do  we  resolve  this  dilemma  in  practice?  We  suggest  the  following 
steps  be  followed  to  provide  sufficient  modulation  to  the  basic  partitioning  concept 
to  assure  its  practicality: 

1)  Develop  an  initial  Hiding  Assumption  List  that  is  as  large 

as  possible while  it  never  helps  to  add  impossible  changes 

to  the  List,  any  other  changes  are  acceptable. 

2)  Order  the  initial  List  according  to  the  probability  of 

occurrence  of  the  change there  is  no  need  to  have  a 

quantitative  measure  of  this  probability,  the  ability 
to  rank  all  changes  according  to  their  relative 
probability  of  occurrence  is  sufficient. 

3)  Determine  what  design  action  is  required  to  minimize 
the  impact  of  each  change.  Categorize  the  impact  of 
each  design  change  on  the  efficiency  of  the  program 
(is  its  impact  on  efficiency  High,  Low,  or  None?) . 

4)  Immediately  accept  the  design  actions  which  have  no 
impact  on  efficiency.  They  represent  design  alternatives 
which  provide  insurance  against  the  corresponding  change 
at  no  cost. 

5)  Review  the  remaining  entries  in  the  ordered  Hiding 
Assumption  List,  starting  with  the  most  probable 
entries.  Determine  the  acceptability  of  each  design 
action  based  on  the  likelihood  of  the  change  and  the 
magnitude  of  the  efficiency  impact.  In  some  cases  it 
will  be  desirable  to  seek  a more  moderate  design  action 
which  provides  some  measure  of  protection  against  change 
but  with  an  acceptable  impact  on  efficiency. 

6)  When  the  inefficiency  in  the  program  has  built  to  the 
margin  of  tolerability,  reject  all  design  actions  which 
lie  lower  on  the  ordered  List. 

This  technique  is  an  attempt  to  buy  the  maximum  insurance  against  program  change  with 
the  minimum  cost  (i.e. , impact  on  efficiency). 

If  the  Hiding  Assumption  List  is  such  a good  communication  medium,  can  it  play 
a role  in  formally  contracting  for  an  avionics  system?  While  we  have  no  current 
experience  on  such  a formal  level,  it  certainly  appears  that  the  Hiding  Assumption 
List  could  be  a very  useful  contractual  vehicle.  In  fact,  whenever  a contracting 
agency  wants  to  impose  a requirement  for  software  flexibility  or  modularity,  it 
cannot  expect  effective  compliance  without  stipulating  the  types  of  changes  to  which 
the  program  will  be  subjected.  The  Hiding  Assumption  List  provides  this  information. 

Even  if  the  Hiding  Assumption  List  is  not  used  as  a formal  contractual  item,  it  is 
important  to  realize  that  the  flexibility  of  a system  design  is  critically  dependent 
upon  the  user's  communication  to  the  designer  of  his  desires  for  future  change 
in  the  system.  There  appears  to  be  no  such  thing  as  flexibility  in  the  abstract. 
Flexibility  means  adaptability  to  change,  and  the  changes  should  be  stipulated. 
Incidentally,  we  would  expect  the  use  of  the  Parnas  Partitioning  concept  and  its 
associated  Hiding  Assumption  List  to  be  easily  generalized  from  software  systems  to 
ANY  systems  for  which  flexibility  is  a design  goal.  These  might  include  GN6.C  systems, 

ECM  systems,  fire  control  systems,  or  even  aircraft,  ships  and  spacecraft. 
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However,  there  is  one  common  objection  to  the  apparent  simplicity  of  the  Parnas 
Partitioning  approach,  which  takes  the  form  of  the  following  observation:  "If  I 

could  specify  all  future  changes  in  a system I could  develop  the  final  system  in 

the  first  place.  But  I don't  know  all  future  changes,  therefore,  the  Hiding  List 
must  be  incomplete".  What  this  objection  fails  to  take  into  account  is  the  fact 
that  the  details  of  the  design  change  do  not  have  to  be  known  in  order  to  construct  a 
Hiding  Assumption  List.  It  is  only  necessary  to  identify  those  design  assumptions 
which  are  likely  to  change.  It  is  NOT  necessary  to  specify  the  new  design  assumption 
for  the  purposes  of  partitioning  the  system  design  to  localize  the  impact  of  a change 
in  design  assumption.  Parnas  Partitioning  can  therefore  be  effectively  used  for  systems 
where  your  only  knowledge  of  a possible  change  is  the  fact  that  your  current  design 
assumption  will  be  revised. 


6.  CONCLUSION 


Our  limited  experience  has  revealed  the  high  utility  of  the  Parnas  Partitioning 
approach  to  the  design  of  flexible  avionics  computer  software.  We  expect  that  the 
technique  is  readily  adaptable  to  all  types  of  software  design  as  well  as  to  the  design 
of  any  complex  system  where  flexibility  is  a design  goal.  In  fact,  imposing  a design 
goal  of  modularity  or  flexibility  WITHOUT  providing  the  associated  Hiding  Assumption 
List  would  appear  to  be  inherently  ineffective.  General  purpose  flexibility  is  likely 
to  prove  to  be  an  ill-defined  goal. 

However,  it  should  not  be  concluded  that  the  Parnas  Partitioning  approach  will 
obsolete  other  modularity  criteria.  It  continues  to  be  desirable  to  have  small, 
manageable  modules  and  the  various  design  criteria  for  their  construction  (see  the 
Introduction  for  a list  of  candidates)  should  be  used  in  conjunction  with  Parnas 
Partitioning  for  best  results. 

For  future  research,  we  would  hope  to  see  the  development  of  a metric  by  which 
the  flexibility  of  a design  could  be  measured.  This  development  would  permit  the 
designer  to  measure  the  effectiveness  of  two  design  alternatives  for  hiding  a particular 
design  assumption  and  thus  permit  an  objective  selection  of  the  best  design  approach. 

At  present,  our  implementations  of  the  Parnas  Partitioning  technique  are  based  on  a 
subjective  selection  among  such  alternatives. 

In  closing  I would  like  to  borrow  a quote  from  the  book  (2)  by  Tom  DeMarco  on 
Structured  Analysis  and  System  Specification  which  underlines  the  importance  of 
designing  to  facilitate  change. 

"The  idea  of  freezing  the  specification 
is  a sublime  fiction. 

Changes  will  not  go  away 

and  they  cannot  be  ignored. " 

so,  we'd  better  learn  to  plan  for  them. 
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Figure  4:  Control  Flow 


DISCUSSION 


Question 

Was  the  use  of  the  Parnas  approach  uniformly  successful  in  your  experience?  We  have  not  been  successful  in 
applying  it  thus  far. 

Author’s  Reply 

While  we  have  not  always  been  successful  in  designing  an  implementation  which  successfully  hides  a particular 
design  assumption  (for  example  the  size  of  the  Kalman  Filter  State  Vector  shown  on  the  JT1DS  hiding  assumption 
list),  we  have  always  been  successful  in  designing  simple  implementations  to  hide  almost  all  of  the  desired  design 
assumptions.  These  design  decisions  represent  a clear  improvement  in  the  flexibility  of  the  resulting  program 
product  so  we  conclude  that  the  Parnas  Partitioning  concept  has  always  been  successful  for  us.  You  should  not 
be  discouraged  by  the  discovery  of  a particular  design  assumption  (such  as  Kalman  Filter  size)  whose  affect  on 
the  program  is  so  pervasive  that  it  defies  local  isolation.  Your  efforts  should  be  concentrated  on  those  design 
assumptions  which  are  amenable  to  isolation.  In  our  experience,  most  design  assumptions  fall  into  this  class 
although  there  is  often  substantial  opportunity  for  design  innovation  in  selecting  the  particular  implementation 
which  most  successfully  facilitates  the  future  program  change. 


A.  Clearwaters 

What  language  was  the  terminal  system  programmed  in? 


Author’s  Reply 

The  terminal  system  was  programmed  entirely  in  Assembler  Language  for  the  SKC31 20  computer.  Extensive  use 
was  made  of  the  floating  point  arithmetic  capability  which  was  built  into  the  computer  and  of  the  Macro  capability 
provided  by  the  Assembler  program. 


A.  Clearwaters 

What  impact  would  the  availability  of  more  modern  language  concepts,  such  as  structures  of  the  form  found  in  C 
or  ALGOL  68,  have  on  your  concepts? 

Author’s  Reply 

The  availability  of  more  modern  language  concepts  would  have  had  no  effect  on  our  program  decomposition 
decisions  using  Parnas  Partitioning  since  these  considerations  are  language  independent.  That  is,  the  selection  of 
the  possible  program  changes  with  high  probability  of  occurrence  is  not  language  dependent,  nor  is  the  decom- 
position of  the  program  into  modules  which  hide  these  design  assumptions.  Thus,  the  availability  of  a high-order 
language  compiler,  such  as  the  SKC  FORTRAN  compiler  which  was  recently  developed  for  our  SKC  3121 
computer,  would  not  affect  our  modularization  although  it  might  have  some  effect  on  some  of  our  implementation 
decisions.  For  example,  since  a source  code  substitution  (Macro)  capability  was  not  provided  by  the  SKC  FORTRAN 
compiler,  we  would  either  have  to  use  sub-routines  in  place  of  macros,  where  that  implementation  selection  was 
made,  or  employ  a FORTRAN  preprocessor  such  as  RATFOR  in  conjunction  with  the  SKC  FORTRAN  compiler 
to  provide  Macro  capability.  In  either  case,  the  modularity  decisions  for  our  program  system  would  be  preserved. 


R. Nelson 

The  examples  of  hiding  assumptions  you  presented  seem  to  apply  at  a high  level  of  program  decomposition.  Did 
you  use  the  list  at  lower  levels  of  decomposition  and  did  you  circulate  the  detailed  assumptions  as  widely  as  those 
at  a higher  level? 

Author's  Reply 

While  the  examples  of  hiding  assumptions  shown  here  are  all  on  a high  level,  they  were  selected  for  presentation 
based  on  their  nnderstandability  by  a mixed  audience  such  as  this.  In  fact  the  wording  of  some  of  them  has  been 
modified  to  increase  clarity.  Our  full  hiding  assumption  list  did  include  many  low-level  design  assumptions  as  well. 
The  full  assumption  hiding  list  was  circulated  to  all  Kearfott  participants  in  the  review  of  the  JTJDS  program  design. 
While  the  full  list  was  available  to  our  customers  as  well,  our  presentations  of  program  status  usually  were  based  on 
the  major  (high-level)  design  decisions  and  they  were  encouraged  to  participate  on  this  level. 
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HIGH  ORDER  LANGUAGE  STANDARDIZATION 
S.A.DiNitto,  Jr 

Rome  Air  Development  Center 
Rome,  N.Y.  13440 
USA 

ABSTRACT 

Standardization  is  approaching  us  from  virtually  every  aspect  of  the  computer  world,  but 
nowhere  is  standardization  of  hardware  and  software  receiving  more  emphasis  than  within  the 
Department  of  Defense  (DOD).  This  paper  explores  one  aspect  of  DOD  standardization, 
namely,  High  Order  Programming  Languages  (HOLs).  Serious  attempts  at  110L  standardization 
have  been  with  the  general  computing  community  for  close  to  two  decades  and  with  the  military 
for  over  ten  years.  HOL  standardization  has  remained  one  of  the  most  visible,  yet  relatively 
unsuccessful  and  controversial  efforts  in  DOD.  The  reasons  for  this  situation  and  the  rationale 
for  the  new  DOD  approaches  to  HOL  standardization  are  discussed  from  the  historical, 
technical,  and  political  standpoints.  Special  emphasis  is  given  to  the  Air  Force  standard  HOLs 
known  as  JOVIAL  (J3)  and  JOVIAL  (J73). 


HISTORY 

The  first  FORTRAN  compiler  was  issued  at  the  beginning  of  1957,  and  by  the  end  of  1963,  there  were  at  least  43 
compilers  carrying  the  name  “FORTRAN”  in  their  designation.  Sammet  (Samml)  provides  evidence  that  not  only  did 
these  implementations  differ  between  manufacturers,  “.  . . but  within  the  same  manufacturer  . . .”  (i.e.  the  same  features 
were  handled  differently  even  on  IBM  machines).  There  should  have  been  an  immediate  lesson  there,  but  for  some 
reason(s)  it  didn’t  take.  Many  people  argued  it  was  still  easier  to  transfer  FORTRAN  programs  from  one  computer  to 
another  than  it  was  to  rewrite  assembly  language  programs  and  were  satisfied  with  that  situation. 

During  the  early  1960’s  there  appeared  on  the  scene  what  has  been  called  the  first  multipurpose  programming 
language,  namely  JOVIAL.  The  language  was  originally  intended  for  Air  Force  Command  and  Control  Systems,  but 
languages  called  “JOVIAL”  have  been  used  by  all  three  services  and  industry  for  the  development  of  Tactical,  Avionics, 
Electronic  Warfare,  data  management,  and  even  airline  reservation  systems. 

There  are  numerous  “dialects”  of  JOVIAL,  which  have  been  given  designations  such  as  JO,  J 1 , J2,  J3,  J4,  J 5 . 1 , J5.2, 
J3B-0,  J3B-1,  J3B-2,  J6  (now  called  SPL),  J73,  J70,  and  JS.  Each  of  these  dialects  will  differ  mildly  or  radically  from 
another  taken  at  random.  Even  within  the  same  dialect,  distinct  implementations  implement  features  differently. 

Directly,  or  indirectly,  the  DOD  has  funded  each  and  every  implementation  of  JOVIAL  or  JOVIAL-like  language. 
For  the  IBM  360/370  computer,  the  following  compilers  have  been  implemented: 

Three  J3  compilers  (each  totally  different  from  the  others) 

Two  J5  compilers  (fairly  similar) 

Four  SPL  (J6)  compilers  (upwardly  compatible  subsets) 

Three  J3B  compilers  (upwardly  compatible  subsets) 

In  addition,  a J73  compiler  is  planned  in  the  near  future  for  the  computer  series. 

Forgetting  for  the  moment  all  the  dialects  and  differences  in  implementation,  DOD  has  obtained  systems  written  in 
many  HOLs.  A representative  list  would  include  AED,  ALGOL,  APL,  BASIC,  CMS-2,  COBOL,  FORTRAN,  JOVIAL, 
LISP,  NELIAC,  PASCAL,  PL-1 , SIMSCRIPT,  SPL,  SPL-1,  and  TACPOL. 

The  above  examples  were  given  to  illustrate  the  two  important  characteristics  DOD  is  now  attributing  to  the  word 
“standardization”  as  it  is  applied  to  HOLs: 

(1)  There  will  be  a single  official  definition  (specification)  of  the  HOL  which  will  be  adhered  to. 

(2)  There  will  be  only  a few  HOLs  and  “dialects”  of  HOLs  which  are  approved  for  DOD  use. 

Characteristic  (1)  means  that  “like”,  “similar  to”,  and  “is  a subset  of  programming  language  X is  not  acceptable. 

In  laymen’s  terms,  only  oranges  will  be  called  “oranges”  (i.e.  tangerines,  tangelo’s  or  grapefruits  will  be  considered  apples 
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when  compared  to  oranges).  Characteristic  (2)  means  that  there  is  a low  upper  bound  on  the  number  of  languages  that 
DOD  will  use  and  provide  support  for  (i.e.  compiler  developments,  training  aids,  support  tools,  etc.). 

These  ideas  are  certainly  not  new,  and  if  one  takes  the  lime  to  review  references  (WATT1  and  SIIAW1 ) it  is  apparent 
that  studies  performed  in  the  early  1960’s  screamed  for  "...  a standard  programming  language  for  Command  and 
Control”  (WATT1 ). 


Why  then  didn’t  HOL  standardization  of  some  form  come  about  much  earlier?  Actually,  “standardization”  efforts 
for  HOLs  did  begin  in  the  early  1960’s  and  by  1966,  there  existed  United  States  of  America  Standards  Institute  (USAS1) 
standards  for  FORTRAN  and  Basic  FORTRAN.  (USASI  was  renamed  the  American  National  Standards  Institute  (ANSI) 
in  1969.)  By  1967,  the  Air  Force  issued  AFM  100-24,  “Standard  Computer  Programming  Language  for  Air  Force 
Command  and  Control  Systems”  which  established  JOVIAL  (J3)  as  the  standard  for  Command  and  Control  applications 
and  provided  a “standard”  definition  of  the  HOL.  Similar  efforts  were  underway  for  COBOL  and  ALGOL  as  well. 

So,  what  happened?  That  question  is  analagous  to,  “Why  wasn’t  former  President  Nixon’s  voluntary  50  mph  speed 
limit  adopted  by  the  public  in  the  Fall  of  1973?  The  answer  is  it  was  (a)  voluntary  and  (b)  had  no  teeth.  Historically, 
this  is  the  case  with  HOL  standards  which  stopped  after  the  production  of  an  official  specification  of  some  sort. 


Each  of  us  who  did  not  heed  the  voluntary  50  mph  speed  limit  knows  why,  but  why  the  resistance  to  HOL 
standardization?  The  following  is  a representative  list  of  actual  reasons  why  a particular  standard  HOL  was  not  adopted 
or  its  official  specification  not  adhered  to: 

( 1)  "Language  XYZ  is  going  to  be  available  some  day  soon  and  it  should  meet  my  needs  better.”  Usually  if  XYZ 
even  came  about  it  became  necessary  to  wait  for  ABC  which  would  be  available  next  year. 

(2)  "Allowing  me  to  add/delete/modify  these  features  will  allow  me  to  optimize  the  compiler/take  advantage  of 
my  hardware/save  money.” 

(3)  “Standardization  will  stagnate  the  state  of  the  art.” 

(4)  “Professor  What’s-His-Name  said  that  language  is  aesthetically  unpleasing/doesn’t  have  string  concatenation/ 
cramps  his  style.” 

(5)  “Not  invented  here.” 

(6)  "The  compiler  doesn’t  produce  efficient  object  code.” 

(7)  “I  can’t  afford  a compiler.” 

(8)  “The  compiler  will  take  too  long  to  develop.” 

(9)  “We  didn’t  use  that  language  the  last  time  and  the  system  worked.” 

(10)  “They  told  me  it  was  language  QBX  when  I bought/leased  the  compiler,  and  its  too  late  to  change  now.” 

(11)  “What  standard?” 

( 1 2)  “That’s  not  what  I thought  the  specification  said.” 

( 13)  “That  language  is  no  good  for  ‘real-time’.” 

It  is  the  opinion  of  many,  including  those  who  have  drafted  the  most  recent  DOD  and  Air  Force  policies  on  HOL 
Standardization  and  those  who  advocate  the  development  of  the  DOD  Common  HOL  commonly  referred  to  as  DOD-1 
that  a strong  standardization  program  won’t  have  much  effect  on  the  first  five  of  the  above  reasons,  but  could  even 
eliminate  most  of  the  others. 


STANDARDIZATION  TOOLS 

The  definition  of  what  is  “strong”  standardization  of  HOLs  differs  among  organizations  and  individuals  imple- 
menting such  standardization,  but  almost  without  exception,  it  is  now  generally  agreed  that  a specification  is  not  enough. 
Over  the  past  decade,  various  concepts,  elements  of  policy,  and  even  tangible  tools  have  arisen  which  support  various 
approaches  to  HOL  standardization.  The  tools  will  now  be  described  independently  of  any  particular  philosophy  of  the 
day. 

( 1)  The  Formal  Specification:  A problem  that  has  plagued  both  official  and  unofficial  HOL  specifications  from 
the  very  beginning  is  their  ambiguity  of  interpretation.  The  earlier  FORTRAN  specifications  consisted  only  of  English 
text  and  examples.  English  is  of  course  ambiguous,  and  when  the  paper  by  John  Backus  (BACK1)  used  a formal  notation, 
now  known  as  Backus  Normal  Form  (BNF),  to  handle  the  syntax  of  ALGOL,  it  was  a welcome  blessing.  However,  while 
BNF  like  descriptions  are  still  popular  and  can  even  be  checked  for  ambiguity  and  completeness  by  feeding  them  into 
automated  tools  referred  to  as  meta-compilers  or  compiler  writing  tools,  BNF  does  not  describe  the  semantic  and  the 
"context-sensitive”  parts  of  a HOL  description.  In  the  late  I960’s  and  early  1970’s,  vehicles  appeared  for  providing  the 
complete  (syntactic  and  semantic)  descriptions  of  a programming  language  in  a formal,  mathematically  rigorous  manner. 
While  these  formal  specifications  have  proved  difficult  to  read  by  laymen,  they  have  been  successfully  used  to  locate 
incomplete  and  otherwise  ambiguous  parts  of  HOL  specifications  which  use  some  natural  language  such  as  English  as 
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part  of  the  description  mechanism.  Two  of  the  more  successful  formal  specification  tools  are  known  as  Hoare’s 
Axiomatic  Method  (llOARI)and  the  Semantics  Oriented  Language  (SEMANOL)  (BELZ 1 ).  The  SEMANOL  development 
was  Air  Force  sponsored  and  SEMANOL  has  been  used  to  specify  JOVIAL  (J3),  JOVIAL  (J73),  BASIC,  and  CMS-2. 

(2)  The  Compiler  Validator:  A tool  which  has  proved  valuable  to  virtually  every  serious  HOL  standardization 
effort  is  the  set  of  test  programs  which  test  for  a compiler’s  adherence  to  the  HOL  specification.  An  official  specification 
coupled  with  a compiler  validator  (the  test  programs)  provide  an  effective,  yet  austere  mechanism  for  enforcing  standardi- 
zation. Of  course,  some  kind  of  legislation  is  necessary  to  require  that  a compiler  pass  all  the  validation  tests  before  it  is 
accepted.  At  present,  there  are  two  problems  with  state-of-the-art  compiler  validators,  namely  their  inability  to  trap 
language  extensions,  and  their  lack  of  rigor  in  testing  those  complex  black  boxes  called  compilers. 

(3)  The  Compiler  Generator,  sometimes  called  the  Root  Compiler:  The  HOL  is  absolutely  useless  without  a 
compiler,  and  the  long  time  necessary  to  develop  compilers,  the  high  cost,  and  the  generally  unstable  condition  of  a new 
compiler  were  and  can  still  be  good  reasons  for  not  using  a HOL.  Some  compilers  have  taken  25  man  years  of 
experienced  talent  and  as  long  as  three  years  to  develop  to  a stable  state  (STEE1). 

Sammet  states  that  ”...  a very  bad  compiler  may  render  the  language  useless”.  Experience  has  taught  that  the  bulk 
of  the  users  do  not  really  distinguish  between  the  compiler  and  the  language  itself,  and  judge  the  language  solely  on  the 
compiler  they  are  familiar  with.  Thus,  the  availability  of  high  quality  compilers  is  absolutely  essential  for  language  stan- 
dardization to  be  accepted. 

Up  to  70  percent  or  more  of  a compiler  can  be  totally  machine  independent,  and  even  some  early  compiler  writers 
tried  to  capitalize  on  this  characteristic  to  cut  down  on  development  cost  and  time  and  not  “reinvent  the  wheel”  with 
each  new  compiler  implementation.  The  basic  approach  is  to  logically  separate  the  machine  dependent  and  machine 
independent  compiler  parts  to  the  greatest  degree  possible  and  then  code  the  compiler  in  its  own  language  (such  as 
JOVIAL),  a special  compiler  writing  language  (such  as  SYMPL),  or  a popular  programming  language  (such  as  FORTRAN). 
This  approach  is  often  coupled  with  the  use  of  a tool  known  as  a meta-compiler  or  compiler-compiler  which  takes  a BNF- 
like  (or  similar)  description  of  a programming  language  and  automatically  produces  the  lexical  and  syntactic  analysis  parts 
of  a compiler.  The  bulk  of  the  work  required  to  get  the  compiler  to  run  on  a different  computer  and/or  get  it  to  produce 
code  for  a different  computer  will  be  concerned  with  modifying  the  code  generation  portion  of  the  compiler  and  (the 
computer  dependent  part)  to  produce  code  for  the  new  computer.  Dunbar  (DUNB1 ) and  Gries  (GRIE1)  provide  good 
tutorials  on  these  techniques. 

Almost  every  new  compiler  built  today  employs  some  variation  of  the  above  because  of  the  following  benefits: 

(a)  The  lower  cost  and  shorter  development  time  for  subsequent  implementations  is  attractive. 

(b)  The  overall  quality  of  the  compiler  will  be  preserved  or  increase  throughout  subsequent  implementations. 

(c)  Maintenance  costs  can  be  spread  over  several  implementations. 

(d)  The  language  processed  will  be  consistent  across  all  implementations. 

(e)  The  same  training  and  programming  aids  can  be  used  across  different  implementations. 

Th»  above  benefits  have  led  some  individuals  and  organizations  to  the  conclusion  that  the  true  path  to  HOL  stan- 
dardization is  to  require  the  use  of  a single  compiler  generator  or  root  compiler  for  all  implementations  of  the  language. 

(4)  The  Code  Auditor:  This  tool  was  invented  for  use  with  compilers  that  may  have  extensions  beyond  or 
deviations  from  the  standard.  This  program  is  often  implemented  as  the  pre-pass  to  a compiler  and  flags  the  use  of 
features  which  are  to  be  avoided.  Variations  on  this  theme  are  now  used  to  enforce  coding  standards  such  as  “structured 
programming”. 

(5)  The  Statistics  Collector:  This  tool  provides  data  on  how  the  language’s  features  are  being  used,  misused,  and / 
or  unused.  If  it  is  planned  to  modify  or  update  the  language  to  conform  to  modern  requirements  or  programming  style, 
to  tune  portions  of  the  compiler  to  be  optimal  for  various  applications,  or  to  identify  troublesome  features,  this  tool  can 
be  extremely  valuable  and  provide  concrete  data  where  opinion  and  general  intuition  was  the  primary  motivation  for 
decisions  in  the  past.  For  example,  the  tool  described  in  (WHIT1 ) has  provided  the  ANSI  BASIC  committee  with  data 
which  has  been  used  to  reject  the  idea  of  a “continuation”  line  (it  showed  the  average  BASIC  statement  to  b»  about  20 
characters)  and  settle  arguments  on  the  final  value  of  the  loop  control  variable. 

(6)  Language  Support  Environment:  Such  environments  consist  of  several  tools  which  support  the  use  of  the 
language  by  making  various  tasks  associated  with  the  development  and  maintenance  of  software  more  efficient  and  less 
risky.  Such  tools  are  generally  very  sensitive  to  any  changes  in  the  syntax  and  semantics  of  the  language  they  support. 

This  directly  promotes  the  use  of  the  HOL  as  well  as  standardization.  The  high  cost  of  some  of  these  tools  also  forces 
standardization  on  a very  few  HOLs,  especially  when  people  become  dependent  on  the  tools.  Examples  of  such  tools  are 
Path-Testers  (GANN1),  Programming  Support  Libraries  (TINA1),  Formal  Verification  Systems  (ELSPI),  and  Code 
Auditors  (SMITI ) like  those  discussed  previously. 
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OFFICIAL  ACTION 

Regardless  of  the  quality  of  the  tools  available,  standardization  cannot  be  effective  without  some  official  sanction. 
Within  DOD,  this  sanction  has  come  with  Department  of  Defense  Directive  5000.29  (DODD1 ) and  Department  of 
Defense  Instruction  5000.31  (DODII). 

Department  of  Defense  Directive  5000.29  requires  that  only  DOD  approved  HOLs  be  used  to  develop  Defense 
system  software,  and  that  each  approved  HOL  be  assigned  to  a control  agent.  The  control  agent  “ . . . will  be  responsible 
for  such  activities  as  validating  compliance  of  compiler  implementations  with  the  standard  language  specifications, 
gathering  data  as  to  the  use  of  the  language  ...”  and  . . assuring  language  stability”. 

Department  of  Defense  Instruction  5000.3 1 lists  the  DOD  approved  HOLs  cited  above  along  with  their  official 
specifications.  The  approved  HOLs  are  FORTRAN,  COBOL,  SPL-1,  CMS-2,  TACPOL,  JOVIAL  (J3)  and  JOVIAL  (J73). 
Control  responsibilities  are  assigned  for  each  HOL:  CMS-2  and  SPL-1  are  to  be  controlled  by  the  Navy;  TACPOL  by  the 
Army,  the  two  versions  of  JOVIAL  by  the  Air  Force;  and  FORTRAN  and  COBOL  by  the  DOD  Comptroller.  The  final 
key  element  of  the  Instruction  is  that  the  control  agents  will  be  allowed  to  extend  and  improve  their  designated  HOLs 
once  per  year  to  meet  changing  requirements. 

Air  Force  Regulation  300-10  (AIFR1)  specifies  that  the  Air  Force  Systems  Command  (AFSC)  will  be  the  control 
agent  for  the  two  versions  of  JOVIAL,  and  limits  the  Air  Force  to  use  only  the  approved  HOLs  FORTRAN,  COBOL, 
JOVIAL  (J3)  and  JOVIAL  (J73).  AFSC  has  responded  to  its  JOVIAL  responsibilities  by  setting  up  an  initial  control 
mechanism  (RADC1 ),  with  the  principal  players  being  the  Computer  Resources  Planning  section  of  AFSC  (AFSC/XRF), 
the  Rome  Air  Development  Center  (RADC),  a Focal  Point  for  each  DOD  user  organization,  all  DOD  and  industry 
JOVIAL  users,  and  last  but  not  least,  HQ  USAF. 

The  Computer  Resources  Planning  section  is  the  Designated  Control  Agent  for  JOVIAL.  (Hereafter  in  this  paper, 
“JOVIAL”  will  meantoth  approved  dialects  of  JOVIAL  unless  otherwise  stated.)  The  Designated  Control  Agent  is  the 
only  real  power  in  that  he  has  the  final  word  on  any  action  concerning  both  the  policy  with  regard  to  JOVIAL  and  the 
actual  language  itself.  He  assures  that  DOD  and  Air  Force  policy  is  followed,  seeks  exceptions  to  higher  authorities’ 
policies  when  necessary,  and  has  the  final  decision  on  language  extensions.  When  the  developer/user  of  a weapon’s  system 
is  an  element  of  AFSC,  the  DCA  and  the  other  players  have  further  duties  which  will  not  be  discussed  here. 

Due  to  the  complex  nature  of  HOLs  such  as  JOVIAL,  the  Designated  Control  Agent  has  delegated  the  technical 
“legwork”,  associated  with  control  of  the  language  and  support  of  the  users,  to  the  JOVIAL  Language  Control  Agent. 

For  an  approximate  two  year  period,  RADC  will  be  the  Language  Control  Agent,  with  this  responsibility  being  trans- 
ferred elsewhere  after  that  period. 

The  Language  Control  Agent  has  the  actual  responsibility  for  assuring  the  stability  and  configuration  of  JOVIAL. 

In  that  capacity  he  provides  recommendations  to  the  Designated  Control  Agent  on  proposed  language  extensions  and 
deviations  and/or  their  use,  and  maintains  a service  center  for  technical  language  expertise.  That  service  center  is  now 
known  as  the  Language  Control  Facility  and  has  the  following  responsibilities: 

( 1 ) Maintenance  of  the  approved  baseline  JOVIAL  Standard. 

(2)  Maintenance  of  a directory  of  standard  compilers. 

(3)  Testing  compilers  for  adherence  to  the  approved  standard  specification. 

(4)  Providing  technical  advice  to  users  on  the  language  and  compiler  development  and  acquisition. 

(5)  Providing  all  necessary  administrative  support  to  an  official  JOVIAL  Users  Group  (discussed  below). 

The  Focal  Point  is  selected  by  the  product  division,  laboratory,  or  participating  major  command  and  approved  by 
the  Designated  Control  Agent.  His  primary  function  is  to  assure  communication  between  the  organization  he  represents 
and  the  other  language  and  policy  control  mechanisms.  He  is  the  interface  to  the  user  community,  provides  advice  on 
HOL  standardization  issues,  and  reviews  and  coordinates  requests  (from  those  he  represents)  for  use  of  non-approved 
languages  and  proposed  changes  to  the  language  standards. 

The  Language  Control  Agent,  the  Designated  Control  Agent,  and  the  Focal  Points  together  form  a Language  Control 
Board  which  is  chaired  by  the  Language  Control  Agent.  The  Board’s  function  is  to  review  and  make  recommendations 
regarding  proposed  changes  to  the  JOVIAL  language  standards. 

A JOVIAL  user  is  any  person  or  organization  which  uses  or  contemplates  using  JOVIAL.  These  users  are  organized 
into  a users  group  which  provides  a forum  for  discussing  language  issues;  provides  solicited  and  unsolicited  inputs  on 
language  changes,  subsets,  user  experience  with  the  language,  compilers  and  support  tools;  and  reviews  and  comments  on 
proposed  revisions,  to  the  language  standard,  made  by  the  Language  Control  Board.  The  Users  Group  will  elect  its  own 
officers,  and  theretore  will  be  relatively  independent  of  the  control  mechanism  itself. 

HQ  USAF  is  in  the  chain  because  when  an  .Air  Force  organization  or  system  developer  wishes  to  use  a HOL  not 
approved  for  Air  Force  use  (as  per  A'r  Force  Regulation  300-10),  HQ  USAF  will  have  the  final  decision  on  whether  or 


not  that  wish  will  be  granted.  HOLs  which  require  such  a waiver  from  HQ  USAF  are  subsets  of  Air  Force  approved 
HOLs,  other  non-standard  dialects  of  Air  Force  approved  HOLs,  all  HOLs  not  listed  in  AFR  300-10  (whether  or  not  those 
HOLs  are  approved  via  Department  of  Defense  Instruction  5000.31)  and  PL-1.  PL-1  is  singled  out  because  while  listed  in 
AFR  300-10,  it  is  not  approved  for  defense  systems. 

Although  there  are  numerous  details  which  describe  the  inner  workings  of  this  control  mechanism,  they  will  not  be 
elaborated  on  here  with  the  exception  of  the  mechanism  for  proposing  changes  to  one  of  the  standard  JOVIAL  defini- 
tions. All  requests  for  language  changes  will  be  submitted  to  the  Language  Control  Agent  for  review.  The  Agent  will  then 
submit  the  proposed  change  to  the  User’s  Group  for  review  and  comment.  The  change  request,  and  the  results  of  all  prior 
reviews  will  then  be  provided  to  the  Language  Control  Board  who  will  make  a recommendation  to  the  Designated  Control  ] 

Agent,  and  simultaneously  provide  that  recommendation,  which  includes  detailed  syntax  and  semantics  if  necessary,  to 
the  User’s  Group.  The  Designated  Control  Agent  will  use  the  Board’s  recommendation  and  the  inputs  of  the  User’s 
Group  to  arrive  at  a final  decision  regarding  the  proposed  change. 

A comparison  of  the  Air  Force’s  approach  to  JOVIAL  standardization  and  the  United  Kingdom’s  (UK)  procedures 
for  standardizing  on  and  controlling  CORAL  66  may  give  the  reader  an  appreciation  for  some  of  the  finer  details  of  the  Air 
Force  approach,  since  CORAL  66  remains  one  of  the  best  military  HOL  standardization  efforts.  Neve  (NEVE1)  gives  a 
concise  description  of  the  history  and  status  of  the  UK’s  standardization  on  CORAL  66  for  real  time  military  systems, 
and  is  the  prime  source  of  the  CORAL  66  data  related  here. 

Neve  points  out  that  "By  the  end  of  1966  ....  there  were  three  essential  ingredients  neccessary  for  the  establish- 
ment of  a language  standard”.  All  three  of  those  ingredients  parallel  the  situation  with  regard  to  JOVIAL: 

(1)  Top  managment  within  the  Ministry  of  Defense  (MOD)  recognized  the  benefits  of  software  and  hardware  stan- 
dardization and  provided  a policy  decision  favoring  the  adoption  of  a HOL  standard. 

(2)  The  technical  people  needed  a well  defined  standard  to  test  compiler  generation  methods.  In  the  case  of 
JOVIAL,  there  are  also  other  HOL  support  tools  that  require  a firm  specification  to  be  cost  effective. 

3)  There  was  an  existing  language,  CORAL  64,  similar  to  JOVIAL,  which  was  a suitable  starting  base  for  the 
standard. 


The  CORAL  66  specification  was  not  frozen  for  some  years,  and  Neve  warns  “The  temptation  to  freeze  the  specifi- 
cation too  early  should  be  resisted”.  This  is  part  of  the  reason  for  the  language  change  mechanism  in  the  control  of 
JOVIAL,  but  unlike  the  situation  with  CORAL  66  which  was  frozen  (i.e.  no  further  changes)  in  1970,  it  is  not  planned  to 
freeze  the  JOVIAL  specifications  at  any  time. 

The  CORAL  66  control  mechanism  includes  an  official  technical  body,  like  the  JOVIAL  Language  Control  Board, 
which  addresses  technical  issues  and  proposals  regarding  the  language,  as  well  as  a technical  organization,  like  the  JOVIAL 
Language  Control  Facility,  which  validates  and  certifies  compilers.  Since  no  changes  are  allowed  to  the  language,  a 
CORAL  66  compiler  is  “certified”  forever.  Because  changes  may  come  to  JOVIAL,  it  was  decided  to  revalidate  compilers 
for  each  specific  use  to  ensure  the  latest  version  of  the  language  is  used. 

The  CORAL  66  control  mechanism  and  the  MOD  do  not  deal  directly  with  the  development  of  CORAL  66 
compilers.  MOD  system  builders  are  free  to  select  from  many  computers  on  an  approved  list,  but  an  essential  require- 
ment to  get  on  that  list  is  a certified  CORAL  66  compiler  maintained  by  the  hardware  vendor.  A waiver  is  required  for 
the  use  of  any  non-approved  computer  and  HOL. 

Historically.  DOD  has  been  directly  involved  with  compiler  development/procurement,  and  until  the  standardiza- 
tion effort  is  mature,  it  must  continue  to  do  so.  Hence,  the  Language  Control  Facility  will  assist  DOD  users  in  procuring 
and  maintaining  JOVIAL  compilers.  At  the  time  of  this  writing,  industry  has  taken  the  DOD  direction  seriously  enough 
to  initiate  its  own  compiler  developments.  Rest  assured  that  the  JOVIAL  mechanism  is  intended  to  and  prepared  to 
support  and  control  both  DOD  and  other  sponsored  compilers. 

Encouraged  by  the  success  of  the  CORAL  66  standardization  and  control  efforts,  and  by  standardization  advantages 
claimed  by  the  three  services  in  DOD,  the  planners  for  the  DOD  Common  HOL,  intended  to  eventually  replace  all  “DOD- 
unique"  HOLs  like  JOVIAL,  have  definite  ideas  for  controlling  their  resulting  language.  Although  nothing  is  official  as 
yet,  it  is  planned  to  place  strict  controls  on  that  HOL  (similar  to  those  on  CORAL  66)  yet  provide  a variety  of  user 
services  and  support  (similar  to  those  available  for  JOVIAL  users). 


BENEFITS 

This  paper  thus  far  has  only  indirectly  referred  to  any  benefits  that  may  accrue  from  HOL  standardization.  Neve 
(NEVE1 ) states  that  certain  benefits  became  apparent  after  a few  years  of  CORAL  66  standardization,  so  rather  than 
provide  conjecture  about  potential  benefits,  the  following  are  taken  directly  from  his  paper  verbatim,  and  without 
comment: 


( 1 ) “The  time  taken  to  implement  systems  is  reduced.” 
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(2)  "The  output  of  programmers  is  increased.” 

(3)  “The  standard  of  documentation  is  higher  and  the  program  structure  more  visible.” 

(4)  “Systems  are  easier  to  hand  over  to  the  user  since  they  will  be  in  a language  understood  by  all  involved  parties. 
This  results  in  reduction  in  the  time  taken  for  handover.” 

(5)  “Systems  can  be  more  easily  maintained  by  the  user.” 

(6)  “Systems  can  be  more  easily  extended  or  modified  by  the  user,  rather  than  by  the  contractor,  whose  original 
team  is  probably  dispersed  anyway." 

(7)  “Estimates  of  software  cost  and  development  time  can  be  assessed  better,  based  on  cumulative  experience.” 

(8)  “The  time  to  train  key  servicemen  is  reduced  and  rationalized.” 

(9)  “Programmers  become  more  transferable  and  thus  fit  in  better  with  service  requirements.” 

(10)  “Some  degree  of  program  transferability  may  be  achieved.” 

(11)  "The  adoption  of  such  a policy  imposes  a degree  of  rationalization  in  the  procurement  of  computers  for 
defense.” 

(12)  “There  is  a consequent  reduction  in  spares  backing  and  specialist  test  equipment.” 

(13)  “There  is  a consequent  reduction  in  the  need  for  skilled  manpower,  which  is  hard  to  recruit  and  retain,  to  have 
knowledge  of  a wide  range  of  computer  hardware.” 

(14)  “Some  degree  of  interchangeability  of  hardware  modules  is  achieved.” 

Its  too  early  to  give  a measure  of  success  for  the  DOD  or  Air  Force  HOL  standardization  programs.  When  the  day 
comes  to  assess  that  success,  it  may  be  very  difficult  to  provide  accurate  quantitative  data  to  the  decision  makers  who  will 
decide  the  future  fate  of  these  programs.  These  people  will  want  to  know  not  only  what  it  cost,  which  is  measurable,  but 
what  it  saved,  which  is  elusive.  If  a defense  system  comes  closer  to  cost,  schedule,  and  expected  performance  because  of 
HOL  standardization,  who  will  brag?  If  a system  developer  felt  that  standardization  is  a thorn  in  his  side,  he  will  be  most 
vocal. 

Recognizing  this  dilemma,  the  Air  Force  has  set  up  its  control  mechanism  with  service  to  the  user  as  a primary 
concern,  and  will  examine  its  mechanisms  and  policies  and  their  effects  on  a yearly  basis.  In  this  way,  negative  and 
positive  aspects  can  be  rectified  and  reinforced  respectively,  and  both  qualitative  and  quantitative  data  can  be  recorded 
while  still  fresh. 
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DISCUSSION 


Jaeger 

How  can  the  process  of  HOL-standardization  be  initiated  in  an  international/interorganizational  framework? 

May  AGARD  be  an  appropriate  platform? 

Author’s  Reply  . 

The  people  behind  the  common  DoD  programming  effort  known  as  “DOD-1  ’ are  pursuing  international 
standardization  of  that  language.  There  presently  exists  some  international  standardization  committees  however 
standardization  through  that  process  is  progressing  rather  slowly.  The  DOD-1  people  have  sought  and  received 
active  support  of  the  language  development  from  the  UK,  Germany  and  France.  AGARD  could  most  definitely 
be  a platform  for  such  international-interorganizational  standardization. 


Jaeger 

Are  the  more  recent  developments  (e.g.  PEARL)  more  promising  candidates  for  standardization  than  the  better 
known,  however  possibly  less  powerful  llOLs? 

Author’s  Reply  . . . . . 

Technically  speaking,  the  newer  HOLs  are  better  candidates  for  standardization.  However,  their  lack  ot  general 
availability  on  common  hardware  can  be  a deterrent.  Unfortunately,  historically  most  HOL  standardization 
efforts  have  given  little  consideration  to  the  technical  issues.  It  is  difficult  to  achieve  standardization  within  even 
a single  organization  such  as  the  USAF. 


■ .DldUII  , 

In  the  future  there  will  be  a need  for  interoperability  in  NATO.  Can  you  comment  on  attempts  made  to  reach 
standardization  of  HOL  in  NATO  countries? 

Author’s  Reply  _ , _ . 

At  the  present  time  the  only  effort  that  I know  of  is  semi-official.  That  effort  is  the  UK,  German  and  French 
involvement  in  DOD-1.  1 do  feel  that  HOL  standardization  is  a necessary  requirement  for  interoperability  but 
certainly  not  a sufficient  condition. 


It  was  indicated  that  the  USAF  encourages  users  to  employ  the  standard  Jovial  language.  From  our  perspective, 
permission  to  use  a subset  of  the  large  J73  language  would  be  an  inducement  to  use  Jovial.  However  you  indicate 
that  the  Air  Force  prohibits  the  use  of  a subset  of  the  language.  Can  you  expand  upon  the  rationale  of  this 
apparent  inconsistency? 
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Author’s  Reply 

Very  rarely  has  a subset  been  a “true  subset”.  Portability  of  software  and  programmers  would  be  hurt  by  many 
subsets  which  are  not  contained  in  one  another  but  have  features  not  in  common,  e.g.,  A,  B.  and  C could  be  subsets 
of  D;  but  none  would  be  a subset  of  the  other.  This  would  obviously  cause  increased  overhead  in  managing  the 
standardization  process. 


A.Clearwaters 

What  about  standardizing  the  services  for  multi-tasking  and  other  OS  functions. 

Author’s  Reply 

Right  now  we  don’t  really  know  enough  about  multi-tasking  to  settle  on  a standard.  With  regard  to  the  other  OS 
functions  a common  Job  Control  language  was  once  attempted  and  failed.  The  DOD-1  HOL  will  define  the 
environment  within  which  it  must  operate.  It  can  operate  in  a “vacuum”  of  OS  functions  but  then  the  “compiler” 
would  provide  the  environment. 


PROJECT  WAVtLL 


The  Command  and  Control  Information  System  for  the  British  Army 


R.J.  Fairchild 
Plessey  Radar  Limited 
Addlestone,  Weybridge 
Surrey 
England 


SUMMARY 


This  paper  describes  Project  WAVELL,  the  battlefield  Command  and  Control  Information  System  produced  by 
The  Plessey  Company  Limited  for  the  British  Ministry  of  Defence  (M.  O.  D.).  The  paper  outlines  the  origins  of 
the  requirement,  the  procurement  policy  specified  by  the  M.  O.D.  and  the  configuration  and  functions  of  the  system. 
Current  activities  and  future  plans  are  also  described. 

1.  INTRODUCTION 

1 . l The  Name  WAVE  LL 

The  name  WAVELL  is  a codeword  used  to  facilitate  reference  to  the  WAVELL  system  and  it  is  also  the  name  of 
a British  General. 

1.2  The  Project's  Aim 

The  aim  of  the  project  is  to  provide  ADP  assistance  to  the  staff  in  formation  headquarters  in  1st  British  Corps, 

British  Army  of  the  Rhine  (BAOR) , to  help  them  carry  out  their  command  control  functions.  The  problems  of 
command  and  control  on  the  battlefield  have  been  the  subject  of  studies  and  research  for  many  years  in  many  parts 
of  the  world  and  the  main  conclusion  which  has  been  universally  arrived  at  is  that  the  problem  is  extremely  complex. 

2.  THE  OPERATIONAL  REQUIREMENTS 

2.1  Improved  Efficiency 

It  is  well  known  that  in  a battlefield  environment  a substantial  proportion  of  staff  time  and  of  available  communications 
facilities,  is  spent  on  handling  routine  information,  the  greatest  part  of  which  is  concerned  with  locations.  This 
information  is  acquired,  disseminated  and  subsequently  confirmed  by  using  combat  net  radio  or  trunk  communication. 
The  proportion  of  time  and  facilities  spent  in  these  activities  is  likely  to  increase  as  warfare  becomes  more  mobile, 
and  as  improved  surveillance  systems  increase  the  amount  of  information  generated  for  assessment  by  the  staff. 

ADP  assistance  is  expected  to  substantially  improve  the  efficiency  with  which  staff  can  retrieve,  assess  and  dis- 
seminate battlefield  data. 


2.2  Enhanced  Continuity  of  Command 

Another  battlefield  command  and  control  problem  area  is  that  of  maintaining  continuity  of  command  during  mobile 
warfare.  ADP  facilities  are  expected  to  substantially  reduce  the  time  taken  to  update  the  'Step  Up'  and  alternative 
headquarters  which  are  the  basis  of  that  continuity.  The  current  manual  systems  are  inevitably  slower  than  is 
desirable,  and  the  effectiveness  of  the  process  is  limited  by  delays  in  updating  a headquarters  echelon  on  arrival 
in  a new  location.  ADP  assistance  should  simplify  and  speed  up  the  updating  process  and  allow  changes  of  command 
to  take  place  more  rapidly,  thus  matching  the  mobility  of  the  fighting  troops. 

2.3  The  Pilot  Scheme  (Stage  1) 

The  potential  benefit  of  providing  ADP  assistance  was  agreed  within  the  British  Government's  Army  Department  in 
the  Spring  of  1976.  This  led  to  a decision  to  implement  a limited  pilot  scheme  to  test  the  viability  of  such  a system 
and  check  out  the  basic  assumptions.  It  was  recognised  that  such  a system  would  be  confined  to  providing  assistance 
with  the  handling  of  routine  information,  speeding  up  the  dissemination  of  information  and  ensuring  that  all  head- 
quarters were  operating  on  the  same  basic  data.  The  task  of  map  updating  would  also  be  eased. 

The  problems  associated  with  developing  and  implementing  such  systems  have  been  studied  by  the  Plessey  Company 
and  the  British  Ministry  of  Defence  for  many  years,  and  early  attempts  to  define  fully  the  requirements  invariably 
revealed  their  almost  unbounded  complexity.  Consequently  it  was  decided  that  the  problem  must  be  solved  by 
evolution  from  a simple  base,  and  thus  was  established  the  policy  to  buy  basically  commercial  equipment  'off  the 
shelf',  bring  it  into  service  quickly  and  develop  it  as  experience  was  gained.  This  was  thought  to  be  probably  the 
most  cost-effective  approach  to  defining  the  ultimate  system  in  the  long  term,  and  subsequent  events  have  confirmed 
the  soundness  of  that  policy. 
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2.4  Summary  of  Benefits 

In  summary  the  proposed  system  was  expected  to  yield  the  following  overall  benefit:  It  should  release  the  staff 
for  the  more  important  tasks  of  assessment,  evaluation,  decision  making  and  Issuing  orders.  In  addition  it  was 
anticipated  that  the  automatic  dissemination  of  Information  would  increase  the  availability  of  telephone  channels  on 
the  trunk  communications  network,  and  this  Indirect  benefit  would  improve  voice  communications  between  headquarters 
echelons  and  speed-up  the  passage  of  orders  and  other  high  priority  information.  Furthermore,  the  staff,  having 
gained  practical  experience  of  ADP,  would  be  able  more  realistically  to  state  their  full  requirements  for  the  definitive 
system  that  would  follow  the  pilot  scheme.  Initially,  however,  WAVELL  was  to  be  a simple  Information  storage  and 
retrieval  system  with  a distributed  database,  the  elements  of  which  were  to  be  synchronised  automatically,  using  the 
currently  available  BRUIN  trunk  communications  system  as  a bearer. 

3.  IMPLEMENTATION 

3.1  Summary  of  Implementation  Problems 

At  first  sight  the  task  of  providing  an  ADP  system  for  the  army  based  on  existing  'off  the  shelf'  commercial  equipment 
may  appear  simple.  There  is,  after  all,  nothing  very  difficult  in  providing  a computer  and  backing  store  to  present 
information  on  visual  display  units  or  hard-copy  printers.  Project  WAVELL,  however,  does  involve  solving  a 
number  of  other  problems  which  to  date  have  frustrated  the  efforts  of  some  of  the  best  system  designers  around  the 
world.  For  a start  the  system  must  survive  the  battlefield  environment. 

The  problems  of  extremely  rugged  cross-country  shock  and  vibration  requirement,  extremes  of  temperature  and 
humidity,  very  limited  space,  and  the  uncertanties  of  field  power  supplies,  are  particularly  challenging  when  con- 
sidering basically  commercial  equipment.  In  addition  many  of  the  equipments  must  be  readily  demountable  from 
their  vehicles  for  deployment  in  barns,  cellars  or  tents,  and  easily  handled  by  soldiers  under  extremely  adverse 
conditions  - total  darkness,  rain  or  snow  for  example. 

3.2  System  Configuration 

Figure  1 Illustrates  the  basic  elements  of  a simple  Information  storage  and  retrieval  system.  In  WAVELL  such 
elements  are  Installed  in  operational  army  vehicles  to  provide  an  ADP  capability  at  each  echelon  headquarters. 

Each  headquarters  has  its  own  database  held  on  disc  backing  store,  viewable  by  staff  users  with  the  aid  of  the  central 
processor  and  visual  display  units. 

Such  a capability  at  individual  headquarters  has,  in  fact,  been  shown  to  be  quite  useful  by  itself;  however,  the  real 
problems  of  command  and  control  on  the  battlefield  stem  from  the  need  for  commanders  and  staff  to  have  an  up-to- 
date  and  closely  similar  picture  of  the  battle  wherever  they  may  be  located. 

The  WAVELL  system  is  therefore  required  at  all  times  to  maintain  the  databases  of  headquarters  distributed  across 
a large  area  of  country,  in  close  synchronism.  By  this  means  decisions  of  Commanders  and  staff  may  be  more 
accurate  and  more  timely,  and  change  of  command  when  required  can  be  achieved  much  more  quickly  and  efficiently 
than  is  possible  at  present.  In  addition  the  system  eliminates  many  routine  and  time-consuming  tasks.  To  achieve 
all  this  a fast,  secure  digital  data  network  linking  all  the  processors  and  their  databases  is  essential. 

Figure  2 shows  a typical  part  of  the  network  provided  for  WAVELL  Stage  1 . Corps  and  divisional  headquarters 
locations  are  shown  as  squares  and  at  each  of  them  a WAVELL  system  has  been  provided.  These  are  mounted  in 
standard  army  3-ton  containers  or  shelters  (indicated  by  the  larger  squares)  as  currently  used  in  BAOR,  and  as  a 
temporary  installation  for  Stage  1,  in  Landrovers  at  the  new  armoured  Task  Forces,  as  indicated  by  the  oblongs. 

3.3  Equipment  (Container  Installation) 

The  equipments  in  the  installation  are  shown  in  Figure  3. 

The  processor,  produced  by  Plessey  Peripheral  Systems  Limited,  is  based  on  the  Digital  Equipment  Corporation 
POP  11/34,  and  is  capable  of  addressing  up  to  128-thousand  18-bit  words  of  core  memory.  A fixed  head  disc  random 
access  backing  store  is  used,  having  a capability  of  storing  p to  40Mbits  of  data.  A system  control  printer  is  pro- 
vided for  the  operator,  and  patch  panels  and  line  drivers  for  the  connection  of  remote  visual  display  units  and  printers. 

Exchangeable  20Mbit  four-track  magnetic  tape  cartridges  are  used  for  software  and  database  loading. 

The  interface  to  the  communications  network  is  provided  through  a multiplexer  and  the  vehicle  is  also  provided  with 
an  air  conditioning  unit  (not  shown  in  the  diagram). 

Figure  4 is  a picture  of  the  interior  of  one  of  the  Stage  1 Divisional  headquarters  vehicles  showing  the  processor, 
disc,  control  printer,  tape  drive  and  patch  panels. 

3.4  Equipment  (Landrover  Installation) 

The  Landrover  system  for  the  '-tore  forward  headquarters  contains  similar  equipment  - but  rather  less  comfort  for 
the  occupants  (Figure  5).  Here  too  there  is  a system  control  printer  and  keyboard,  patch  panel  and  line  drivers, 
and  a cartridge  unit  for  loading  the  programmes  and  the  database.  For  the  second  stage  of  WAVELL  this  installation 
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will  be  provided  In  armoured  vehicles.  These  systems  provide  similar  functions  to  the  larger  Installations  but  are 
designed  for  more  forward  deployment  and  to  match  the  greater  mobility  of  command  at  this  level.  Air  conditioning 
equipment  Is  provided  on  the  top  of  the  vehicle.  Figure  6 shows  the  Interior  of  one  of  the  Stage  1 Landrovers. 

3.5  Deployment 

To  help  visualise  how  WAVELL  systems  are  deployed,  the  non-tactical  artisi's  Impression  shown  in  Figure  7 
illustrates  the  basic  elements  of  the  system  in  use.  On  the  hilltop  the  nodes  of  the  communications  network  (the 
Communications  Centres)  Landrover  mounted  systems  are  deployed  alongside  the  existing  Commcen  equipment,  to 
provide  a switching  capability  for  routing  data  through  the  communications  network  to  and  from  the  various  head- 
quarters as,  for  example,  shown  In  the  picture.  The  network  Itself  is  constructed  from  UHF  radio  links  using  the 
existing  BRUIN  communications  equipment  already  deployed  in  BAOR  for  voice,  telegraph  and  facsimile  communi- 
cations. WAVELL  uses  a dedicated  4.6Kbtt'  digital  data  channel  throughout  this  network.  It  must  be  noted, 
however,  that  WAVELL  itself  is  not  a communication  system. 

This  communications  network  is  subject  to  frequent  and  often  unpredictable  reconfiguration  to  meet  operational  needs 
and  changing  tactical  situations.  As  with  all  such  systems  the  links  from  time  to  time  are  susceptible  to  interference 
in  varying  degrees,  including  jamming  and  destruction  by  enemy  action.  Redundancy  in  the  network  and  the  provision 
of  alternative  paths  is  therefore  an  important  consideration,  as  is  the  detection  and  correction  of  errors  in  the  data. 
Data  is  divided  into  small  messages,  or  packets,  to  Increase  the  probability  of  successful  transmission  through  the 
network. 

The  problems  of  controlling  such  a network  are  complex  and  the  WAVELL  vehicle  illustrated  on  the  left  in  Figure  8 
provides  the  system  control  facilities  which  are  essential  to  the  successful  management  of  the  system.  Also  shown 
in  this  illustration  is  a WAVELL  display  unit  in  a staff  vehicle  (on  the  right)  being  used  in  close  conjunction  with  the 
all-important  map.  It  is  not  feasible  at  this  stage  to  provide  automatic  map  display  facilities  although  much  work  is 
in  hand  in  different  parts  of  the  world  to  find  a cost-effective  solution. 

3.6  Major  Technical  Problem  Areas 

The  successful  implementation  of  the  project  has  been  critically  dependent  upon  the  resolution  of  problems  in  two 
major  technical  areas:- 


(a)  The  management  and  control  of  the  databases  throught  the  system  and 
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(b)  The  provision  of  an  efficient  communications  system  for  fast,  robust  message  switching. 

The  details  of  the  software  design  used  in  these  two  important  areas  cannot  be  described  in  this  paper  for  security 
reasons.  Suffice  it  to  say  that  the  protocols  for  database  and  communications  management  are  required  to  be  such 
that  data  is  never  lost.  In  practice  it  has  been  found  that  digital  information  can  be  successfully  distributed  when 
adequate  voice  communication  is  not  possible.  The  network  is  continually  monitoring  and  updating  its  own  connectivity, 
and  at  any  time  each  processor  is  aware  of  the  total  network  connectivity  and  may  select  the  optimum  route  to  any 
destination. 

The  design  and  development  of  the  software  for  this  system  has  been  without  question  a major  undertaking  and  the 
most  difficult  part  of  the  whole  programme.  While  ’off  the  shelf  software  such  as  the  RXS11  operating  system 
has  been  used  in  the  development  programme,  the  majority  of  the  software  has  been  tailor-made  for  the  application. 

The  software  is  written  mainly  in  CORAL,  the  language  preferred  for  real  time  systems  by  the  Ministry  of  Defence 
and  the  now  well  established  'top  down'  approach  has  been  followed  for  the  system  design,  followed  by  implementation 
from  the  bottom  (or  module  level)  upwards.  The  total  number  of  man-years  spent  in  the  production  of  Stage  1 soft- 
ware has  been  approximately  70. 

3.7  Summary 

In  summary  then,  we  have  provided  in  an  extremely  short  timescale  a complex  software  system  and  a set  of  rugged, 
mobile  systems,  capable  of  maintaining  synchronised  distributed  databases,  across  a volatile  and  error-prone 
communications  system.  The  system  operates  in  a hostile  electronic  and  physical  environment.  As  far  as  is 
known  such  a system  has  not  been  successfully  achieved  anywhere  in  the  world  before,  and  it  is  believed  to  be  the 
first  effective  battlefield  command  and  control  system  to  be  deployed  in  the  field. 

4.  TIMESCALES 

4 . 1 Overall  Development  Programme 

The  timescale  in  which  all  this  has  been  achieved  is  very  short  indeed,  but  it  has  still  been  necessary  to  compress 
into  it  the  essential  processes  of  feasibility  study,  project  definition,  system  design  and  Implementation.  These 
stages  in  the  systems  procurement  cycle  are  normally  carried  out  sequentially  and  often  over  a period  of  many  years. 

The  tight  timescales  which  have  had  to  be  met  are  illustrated  in  Figure  9.  From  the  summer  of  1976  just  15  months 
were  available  to  build  the  system  and  make  it  available  for  UK  Trials  with  the  Army's  BRUIN  communications 
system  in  the  Autumn  of  1977.  Those  trials  were  completed  on  time  early  this  year,  and  the  Stage  1 system  was 
shipped  to  BAOR  for  use  on  operational  exercises  during  this  summer.  All  the  development  work  and  trials  during 


26-* 


this  period,  and  the  user  trials  In  BAQR  are  called  Stage  1,  The  equipment  supplied  during  this  stage  equips  just 
one  division  of  1st  British  Corps,  plus  the  Corps  headquarters.  After  a period  of  continuing  evaluation  In  BAOR 
further  deployment  of  fully  operational  equipments  lor  the  whole  of  1st  British  Corps  (Figure  10)  will  occur  In  the 
early  1980s. 

The  prospect  of  achieving  a timescale  such  as  this,  rather  like  the  prospect  of  Imminent  execution,  has  concentrated 
minds  wonderfully  on  the  resolution  of  operational,  technical  and  managerial  problems.  It  has  demanded  an  except- 
ionally high  level  of  understanding  and  co-operation  between  customer  and  main  contractor,  and  this  has  been  a 
major  factor  contributing  to  the  success  of  the  project. 

5.  CONCLUSIONS 

In  Stage  1 the  general  concepts  of  Project  WAVELL  have  been  shown  to  be  sound,  and  it  has  been  proved  that  a system 
comprising  processors  based  at  headquarters  locations,  maintaining  synchronised  distributed  databases  using  battle- 
field trunk  communications  is  both  feasible  and  viable.  Most  Important  of  all,  the  army  staff  user  finds  the  system 
to  be  of  considerable  benefit.  The  step  which  has  to  be  made  from  Stage  1 to  Stage  2,  is  simply  to  upgrade  the 
environmental  and  performance  specifications  of  the  system  hardware  and  to  optimise  the  software  design.  The 
Stage  2 system  will  be  to  full  military  environmental  specifications  using  a more  powerfull  processor,  and  solid- 
state  backing  storage.  The  staff  facilities  to  be  provided  will  initially  be  the  same  as  those  provided  In  Stage  1. 
During  its  operational  life  it  is,  however,  anticipated  that  the  facilities  will  be  extended  Into  additional  application 
areas  such  as  logistics,  engineering  and  artillery  and  maybe  one  day  It  will  be  possible  also  to  Include  an  inexpensive 
fully  interactive  multicolour  map  display. 
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Fig.  1 Typical  system  configuration 
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Fig.2  Stage  1 system  diagram 
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Fig.4  Interior  of  Stage  1 Divisional  H.Q.  vehicle 
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Fig. 3 Processor  installation  container 
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Fig.5  Processor  installation  - minor  system 


Fig.6  Interior  of  Stage  1 Landrover 
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Fig.7  Deployment 


Fig.8  System  control  vehicle  (left)  and  staff  vehicle  (right) 
with  WAVELL  display  unit 
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Fig. 9 Implementation 
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Fig.  1 0 WAVELL  system  diagram 
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DISCUSSION 


J.B.Tasche 

Does  the  WAVELL  system  control  the  technical  communications  side  of  the  battlefield  situation,  e.g.  the  timing, 
keying  of  transmitters,  timing  of  receivers,  coordination  of  frequency-hopping  etc.? 

Author’s  Reply 

No.  WAVELL’s  function  is  information  storage  and  retrieval. 


R.  Zimmer 

Is  it  intended  for  WAVELL  to  be  interoperable  with  other  NATO  command  and  control  centers  and  if  so  what  is 
the  progress  towards  that  end? 

Author’s  Reply 

Yes,  work  is  currently  in  progress  and  discussions  have  been  ongoing. 


Question 

Is  WAVELL  considering  problems  of  interoperability? 


Author’s  Reply 

Yes,  but  the  question  we  should  ask  is  interoperability  with  what?  More  seriously,  our  military  team  is  on  a number 
of  NATO  working  groups,  and  we  have  been  conferring  with  military  and  civilian  staff  associated  with  the  TOS 
programme  here  in  the  US. 


MOBILE  TACTICAL  C3  SYSTEMS 
David  Shore 

Division  Vice  President 
Advanced  Programs  Development 
RCA  Government  Systems  Division 
Moorestown,  NJ  08057 

SUMMARY 


In  1968  the  writer  presented  the  keynote  address  at  the  first  "Technology  for  Data  Handling  in  Tactical  Systems" 
meeting  of  AGARD.  The  basic  tenet  was  that  tactical  air  command  and  control  would  need  to  emphasize  physical 
survivability  through  a net  of  mobile,  decentralized  systems. 

Now,  ten  years  later,  the  need  still  exists  and  remains  to  be  satisfied.  Indeed,  it  is  now  clear  that  anti-jam  com- 
munications must  be  added  to  the  list  of  requirements. 

Fortunately,  the  growth  in  technology  predicted  ten  years  ago  has  been  achieved  or  exceeded.  The  concept  of  the 
previously  described  "1975  System"  can  be  built  today. 
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This  paper  describes  an  updated  version  of  the  mobile,  survivable  C concept.  The  basic  building  block  is  a modular 
van  housing  intelligent  terminals,  a miniprocessor  with  high-density  mass  memories,  multiplexed  internal  wiring 
to  permit  rapid  changes  of  equipment,  and  an  anti-jam  communication  system. 

INTRODUCTION 

Ten  years  ago  I presented  the  keynote  address  to  the  AGARD  meeting  on  "Techniques  for  Data  Handling  in  Tactical 
Systems.  " A system  of  mobile,  tactical  C3  systems  was  proposed  to  provide  effective,  survivable  command 
capability.  Technology  developments  to  suppor*  this  concept  were  also  recommended. 

3 

In  the  ensuing  ten  years  the  need  for  such  mobile  C systems  has  been  further  substantiated,  and  the  technology  to 
provide  the  system  design  has  matured. 

The  keynote  speaker  for  this  meeting.  Dr.  I.  Mirman,  has  addressed  the  reasons  for  the  slow  progress  in  survivable 
C3.  I will,  therefore,  concentrate  on  a rationale  for  achieving  the  needed  capability. 

PRIORITY  OF  REQUIREMENTS 

3 

Listing  basic  requirements  for  a mobile,  tactical  C system  is  a relatively  straight-forward  task;  assigning 
priorities,  on  the  other  hand,  becomes  a more  subjective  (and  debatable)  matter.  The  prioritized  list  below  is 
discussed  briefly  in  the  following  paragraphs. 

1.  Survivability 

2.  Affordab  lity 

3.  Preplanning 

4.  Flexibility 

5.  Interoperability 

6.  Capability 

1.  Survivability 

The  considerations  since  the  1968  AGARD  paper  that  raise  survivability  to  the  highest  priority  are: 

3 

The  lessons  of  the  last  war  in  the  Middle  East,  including  the  vulnerability  of  C to  physical  attack  and  electronic 
countermeasures. 

Strategic  analyses  that  conclude  that  NATO  must  cope  with  PACT  use  of  nuclear  weapons  (see  Richard  Pipes, 
"Why  the  Soviet  Union  Thinks  it  Can  Win  a Nuclear  War,”  Air  Force  Magazine.  Sept.  1977). 
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The  dearth  of  truly  hardened  or  truly  mobile  C systems  in  NATO. 

The  growth  of  "Red  Brigades"  which  pose  a serious  sabotage  threat. 

The  overwhelming  historical  record  of  successful  surprise  attacks  despite  strategic  intelligence  that  an  attack 
was  imminent.  Pearl  Harbor  has  had  many  counterparts  before  and  since  its  occurrence. 

One  must  then  conclude  that  a PACT  attack  could  achieve  tactical  surprise,  could  include  nuclear  weapons,  could 
place  high  priority  on  destroying  NATO  C3,  could  be  aware  of  the  location  of  NATO  C3  assets,  could  use  massive 
electronic  warfare  measures,  could  exploit  coordinated  sabotage  attacks,  and  could  - unless  there  is  a significant 
change  - have  a high  expectancy  of  crippling  NATO  C3. 
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If  NATO  C is  to  be  a factor  in  deterring  a PACT  adventure,  or  failing  this,  provide  effective  control  of  NATO  forces, 
then  NATO  C®  must  be  able  to  survive  as  an  effective  mechanism. 

To  survive,  NATO  C'^  must  be: 

a.  Protected  against  CBR  weapons 

b.  Truly  mobile 

c.  Greatly  dispersed 

d.  Difficult  to  identify  and  target 

e.  Defended  against  aircraft,  missile,  and  ground  attack 

f.  Or  some  realistic  combination  of  the  above. 

2.  Affordability 
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If,  despite  the  multi-billion  dollar  investment  in  C to  date,  NATO  lacks  a survivable  C capability,  the  cost  for 
achieving  survivability  must  be  affordable.  With  the  quantitative  balance  of  weapons  such  as  tanks,  artillery,  etc. 
heavily  in  the  favor  of  the  PACT  nations,  allocation  of  funds  for  survivable  C®  will  be  difficult.  Therefore,  it  is 
necessary  to  make  maximum  use  of  standardization,  moderate  performance  demands,  and  existing  military  and  non- 
military resources  to  achieve  affordability.  C®  systems  must  be  designed  to  meet  affordable  production  costs  (DTUPC). 

3.  Preplanning 

If  it  were  possible  to  preplan  for  every  contingency,  encapsulate  th,e  plans  in  a suitcase,  and  provide  every  commander 
with  such  a suitcase  (suitably  protected  against  loss  to  the  enemy,  of  course)  survivable  C®  would  be  a trivial  challenge. 
Unfortunately,  even  with  the  microprocessor  revolution,  this  is  not  possible.  What  is  possible,  however,  is  the 
exploitation  of  superior  knowledge  of  terrain  features  in  our  NATO  countries,  preselection  of  counter-attack  sites 
such  as  choke  points,  and  preplanning  of  cooperative  attack  at  these  points  should  the  opportunity  arise.  Such  plans 
can  be  stored  in  a small  C®,  in  aircraft,  in  tanks,  and  perhaps  even  in  a suitcase.  Promulgation  of  the  contingency 
plan  directive  could  then  be  accomplished  using  many  modes  of  communications  in  the  face  of  even  an  unusually  high 
level  of  enemy  countermeasures.  The  first  rule  in  anti-jam  is  to  require  the  least  amount  of  data  be  transmitted 
over  the  widest  bandwidth  and  most  numerous  independent  communication  systems.  Preplanning  helps  to  achieve 
this  ideal. 

4.  Flexibility 

The  impracticality  of  the  "plan-for-any-contingency-in-a-suitcase"  stems  from  the  infinite  number  of  possibilities 
once  a war  begins. 

If,  for  example,  the  PACT  forces  spare  NATO  cities  in  the  hope  of  capturing  their  manufacturing  capability,  then  the 
survivable  C®  must  be  able  to  exploit  cities  as  a haven.  To  do  so  they  must  be  able  to  communicate  while  hidden  in  a 
building.  This  is  a different  problem  from  communicating  in  the  open. 
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If  the  C must  move  continuously  to  survive,  this  is  a different  communication  problem  than  when  stationary. 
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If  the  C element  is  a part  of  a dispersed,  internetted  C system,  the  element  must  be  reconfigurable  by  software  to 
assume  the  role  of  another  C®  element  which  is  on  the  move  or  which  may  have  been  destroyed. 

No  doubt,  many  other  examples  of  flexibility  will  come  to  your  mind  that  could  enhance  the  ability  of  the  overall 
NATO  C®  system  to  meet  unforeseeable  contingencies. 

5.  Interoperability 

By  presidential  edict,  we  in  the  U.  S.  are  placing  great  emphasis  on  the  interoperability  of  NATO  forces.  We  heartily 
concur  with  the  importance  of  interoperability,  but  in  addition  to  our  language  differences,  we  have  such  differences 
in  our  communication  systems  that  they  do  not  interface  properly. 

Exchange  of  personnel  carrying  their  nation-peculiar  communication  sets  may  be  a cumbersome  but  adequate  solution 
in  our  present  system  of  large  fixed  or  "moveable"  C®  centers.  It  is  impractical  if  we  turn  to  a system  of  dispersed, 
small,  mobile  C®  units  in  order  to  achieve  survivability. 

The  most  promising  solution  is  the  use  of  common  communication  equipment,  frequencies,  modulation,  and  a common 
military  language  (through  the  common  language  may  be  translated  on  a display  into  the  user's  national  language). 

6.  Capability 

It  may  be  very  strange  to  place  capability  at  the  bottom  of  the  priority  list  but  this  may  be  the  price  of  having  any 
capability  at  all  after  a surprise  attack  takes  place. 

Perhaps  it  might  be  more  palatable  to  state  that  we  need  to  prioritize  desired  capability  so  we  can  distinguish 
between  what  is  most  vital  and  what  is  merely  "nice  to  have.  ” By  now  you  will  have  realized  I am  repeating  my 
theme  of  ten  years  ago:  modularized,  mobile  C®  units  serviced  by  suitable  communications.  Even  though 
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technology  predictions  of  ten  years  ago  have  come  to  pass,  we  still  have  a propensity  of  putting  100  kg  of 
potatoes  in  a 10-kg  bag.  To  achieve  our  objectives  we  must  be  highly  selective  in  specifying  capability 
requirements. 
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Before  describing  my  perception  of  the  survivable,  mobile,  modular  C system  of  the  future,  I would  like  to  show 
you  a short  film  extract  which  describes  a demonstrator  system  built  by  RCA  to  develop  an  optimum  RPV  command 
center  concept.  It  will  serve  to  clarify  some  of  the  concepts  I will  describe  later.  The  RPV  mission  is  actually 
compatible  with  my  basic  theme  of  survivability  since  the  RPV  could  be  anything  from  the  mini-RPV  to  the  Ground 
Launched  Cruise  Missile  - all  of  which  are  designed  for  survivability. 


BASELINE  CONCEPT 

To  meet  the  survivability  and  other  objectives,  I suggest  that  a family  of  van-based  mobile  centers  be  developed  using 
common  equipments,  tailored  for  individual  missions  by  software.  The  basic  van  would  be  useful  for  the  NATO 
theatre  or  for  crisis  situations.  For  some  applications  the  center  could  be  contained  in  an  armored  personnel  carrier. 

A commonly  used  van  (2. 46  x 2. 46  x 6. 15  meters  of  8 x 8 x 20  feet)  is  suggested  as  the  means  by  which  identification 
could  be  avoided.  The  van  can  be  mounted  on  a flat  bed  for  mobility,  can  be  concealed  in  wooded  areas  or  urban 
areas  (e.  g.  , moved  into  a garage)  and  can  be  carried  by  cargo  aircraft. 

Each  van  would  contain  *he  following: 


1.  Two  or  three  "smart"  terminals 

2.  Miniprocessors 

3.  Mass  memory  storage 

4.  Communication  terminals 

5.  Auxiliary  power  units  and  necessary  environmental  equipment 

6.  Mission-unique  equipment,  e.g.  radars 

7.  Built-in  test  and  training 
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Different  C organizational  levels;  i.  e. , in  ihe  U.  S,  Air  Force,  TACC,  DASC,  CRC  and  FACP,  would  use  a number 
of  the  basic  vans  appropriate  to  their  mission.  The  vans  making  up  a center  would,  however,  require  the  capability 
of  working  together  while  separated.  Survivability  is  the  driving  force  to  avoid  identifiable  clusters  of  vans.  Should 
a van  be  destroyed,  its  essential  duties  should  be  accommodated  in  the  surviving  vans. 

A more  detailed  discussion  of  the  equipment  in  each  van  follows  to  indicate  how  the  proposed  universality  could  be 
achieved: 


1.  "Smart  Terminals" 

There  is  a wide  variety  of  terminals  in  use  or  in  development.  Yet  the  elements  are  the  same:  computer-driven 
displays  and  entry  devices.  It  seems  extremely  wasteful  to  start  from  scratch  every'  time  with  new  terminals  in  an 
era  when  they  can  be  tailored  by  software  for  different  functions.  We  believe  that  the  behavioral  scientists  have 
provided  a reasonably  clear  set  of  guidelines  on  how  one  should  human-engineer  a terminal  with  almost  universal 
flexibility.  It  could  take  the  following  form  for  our  proposed  van  application. 

Two  displays  per  console  - one  for  alphanumerics  and  one  for  graphics  or  video.  The  alphanumeric  display'  would 
be  computer-driven  to  provide  the  information  the  operator  selects.  It  should  be  in  color  to  indicate  items  of  priority. 
For  example,  a display  listing  status  of  individual  aircraft  could  use  red  letters  for  aircraft  on*  of  commission, 
yellow  for  in-use,  and  green  for  ready  aircraft. 

The  other  display  would  be  used  for  graphics,  maps,  pictures  and  as  a video  terminal  for  closed-circuit  TV  link:  ; 
between  the  vans  that  together  make  up  a C3  system  despite  dispersal  for  safety.  Again,  color  should  be  used  to 
the  operator's  job  easier;  e.  g. , a different  color  for  friend  or  foe. 


The  size  of  the  displays  is  a tradeoff  tween 
size  is  a -easonable  compromise. 


resolution  and  space  limitations  in  the  van.  A twelve-inch  diagonal 


Since  the  displays  are  computer  driven,  additional  aids  can  be  provided  the  operator: 

a.  Fluctuating  intensity  or  color  to  attack  attention 

b.  Electronic  zoom  to  magnify  selected  areao 

c.  Change  or  motion  detection 


The  suggested  entry  system  is  a combination  of: 


a.  Menu-type  keyboar  ! 

b.  Light  pen,  speed  bail,  or  joy  stick 
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The  menu-type  keyboard  provides  the  means  for  customizing  the  terminal  for  the  gamut  of  operator  duties  for  the 
different  positions  in  the  C3  system  (i.  e. , TACC  and  CRC).  Yet  it  does  so  with  a minimum  number  of  keys.  For 
example,  the  top  row  is  tagged  with  the  highest  level  functions  for  the  operator.  When  he  selects  one  of  the  keys, 
say  "enroute  control,"  all  the  other  keys  tn  the  keyboard  are  computer-controlled  to  have  titles  pertinent  to  that 
function. 

Light  pens,  speed  balls,  and  joy  sticks  are  proven  devices  for  quickly  addressing  the  computer  and  obtaining  desired 
actions. 

2.  Mi  nicomputers 

The  advent  of  large  scale  integrated  arrays  and  microprocessors  make  possible  high-capacity  data  processing  in 
small  weight  and  volume.  Certain  of  the  technology,  for  example,  CMOS/SOS,  also  require  modest  power,  generate 
modest  heat,  and  have  inherent  nuclear  hardness. 

Using  these  new  processors  means  each  van  can  be  given  its  own  computer  instead  of  today's  practice  of  using  a 
central  computer.  This  permits  enhanced  survivability  through  redundancy.  Furthermore,  redundant  computers  in 
each  van  should  be  provided  for  reliability. 

3.  Mass  Storage 

Disk  3torage  devices  can  provide  mass  memory  but  are  bulky.  Bubble  and  CCD  memories  are  now  rapidly  evolving. 
These  technologies  should  be  pushed  to  provide  an  adequate  capacity.  A measure  of  adequacy  is  the  ability  to  store 
the  data  necessary  to  permit  the  van  to  perform  the  duties  of  a destroyed  van  as  well  as  its  own. 

4.  Communication  Terminal 

Internal  van  communications  should  include  voice  and  video.  A data  bus  should  be  used  to  link  all  of  the  equipments 
in  the  van  and  to  provide  for  easy  retrofit  of  new  generation  equipment  as  it  becomes  available  - and  necessary.  The 
next  task  is  to  provide  communications  to  link  the  vans  together  while  on  the  move  or  when  dispersed  over  an  area 
approximately  one  mile  square. 

While  on  the  move,  low-power,  millimeter-wave  communication  using  steerable,  directive  antennas  could  provide 
bandwidth  adequate  for  video  and  permit  adequate  data  exchange.  The  low  power  (milliwatts)  is  to  minimize  enemy 
detection.  When  the  vans  are  parked,  fiber  optics  are  very  attractive  interconnects  because  of  their  light  weight, 
non-emissivity,  acceptable  loss  Ail  ometer,  and  bandwidth. 

Exterior  communications  is  a more  difficult  matter.  Here  the  conflict  is  between  adequate  capabity,  anti-jam, 
alternate  routes,  etc. , on  one  hand,  and  avoiding  distinctive  physical  or  electromagnetic  telltales  which  the  enemy 
could  exploit.  The  following  approaches  should  be  considered: 
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a.  Use  a separate  communication  van  linked  by  line  to  the  C van.  There  should  be  standby,  dispersed, 
dormant  communication  vans  to  which  one  could  switch  if  the  first  is  destroyed. 

b.  Use  of  airborne  relays  to  provide  better  screened  paths  to  recipient  forces  in  the  face  of  enemy  jamming. 

c.  Use  of  enemy  frequencies  for  high  priority  transmission  (the  "sanctuary"  approach). 

d.  Use  of  phased  array  antennas  to  provide  multiple,  simultaneous  transmissions,  low  sidelobes,  and  adaptive 
nulling. 

e.  Use  of  satellite  systems  incorporating  anti-jam  capabilities. 

5.  Auxiliary  Power  and  Necessary  Environmental  Equipment 

The  vans  should  be  equipped  for  independent  operation  with  necessary  power  and  environmental  equipment.  Careful 
selection  of  the  C3  equipment  can  minimize  the  power  and  environmental  demands.  Protection  against  nuclear, 
chemical,  gas,  and  small  arms  should  be  provided  to  the  extent  mobility  considerations  permit.  In  addition,  electro- 
magnetic and  IR  radiation  should  be  suppressed  to  avoid  detection. 

t>-  Built-In  Test  and  Training 

The  proposed  independent  operation  of  these  vans  places  a high  premium  on  reliable  equipment,  self-check  capability, 
and  appropriate  spares  provisioning.  The  basic  minicomputer(s)  must  be  sized  to  provide  the  testing  function.  In 
addition,  built-in  training  scenarios  should  be  provided  to  permit  the  operators  to  maintain  their  skills  on  their  prime 
functions  and  to  exercise  them  on  changes  which  might  be  necessitated  by  the  loss  of  other  vans.  To  make  the  training 
"real-world"  it  must  be  done  with  full  recognition  of  EW  factors. 


CONCLUSION 
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I hope  the  case  for  survivable  C is  clear.  The  proposed  baseline  mobile  C concept  requires  and,  I believe, 
deserves  detailed  design  effort.  It  can  provide  a common  approach  which  all  NATO  forces  could  use,  all  nations 
could  build,  and  all  could  afford.  We  cannot  afford  the  present  situation  which  is  an  invitation  to  PACT  adventurism. 
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ABSTRACT 

With  the  advent  of  more  sophisticated  weaponry  systems  onboard  Army  aircraft  and  the  projected 
deployment,  by  hostile  powers,  of  high  speed  detection  and  retalliation  equipments,  a need  for  a fast 
and  reliable  data  handling  system  is  required.  To  this  end,  the  US  Army  Avionics  R&D  Activity,  Aviation 
Research  and  Development  Command,  has  embarked  on  a pioneering  investigation  and  hardware  feasibility 
development  effort  to  demonstrate  with  the  user  an  inter-aircraft  and  aircraft  to  ground  data  handling 
system  which  will  be  capable  of  transmitting/receiving  tactical  data  employing  data  enhancement  techniques 
to  improve  reliability  in  a Nap-of-the-Earth  (NOE)  operational  environment.  The  control  section  of  the 
ADTS,  although  confined  to  one  black  box,  is  broken  into  two  functional  control  areas:  control  of 
communications  Transmit /Receive  Controller  Module  (TRCM)  and  control  of  data  gathering  from  onboard 
subsystems  System  Controller  Module  (SCM).  The  interface  ports  of  the  SCM  and  the  TRCM  can  be  configured 
to  match  the  protocol  and  hardware  requirements  of  any  onboard  candidate  system.  The  ADTS  also  incorpor- 
ates a data  and  control  input  keyboard  for  operator  intervention  and  an  alpha-numeric/graphical  display 
to  provide  visual  data  output  in  the  form  of  text,  prompting  messages,  course  information,  and  display 
of  spacial  relationships  between  aircraft  and  targets.  In  a typical  application,  data,  such  as  target 
coordinates  and  aircraft  status  and  location  etc.  would  be  transferred  between  scout  aircraft  and  attack 
aircraft  or  ground  observer  and  aircraft.  Data  handling  would  be  performed  in  a semi-asynchronous  manner 
employing  a realtime  designated  control  system  but  at  the  same  time  allowing  any  aircraft  to  access  any 
other  aircraft  without  control  system  intervention.  A scheme  is  provided  to  allow  source  to  destination 
addressing,  however,  all  systems  on  the  same  network  would  receive,  for  data  base  update  purposes,  data 
being  passed  between  any  two  data  systems. 

1.  BACKGROUND 

In  past  conflicts  involving  scout  and  gunship  scenarios,  a great  deal  of  difficulty  was  experienced 
in  detection  of  targets  by  scout  aircraft  and  transfer  of  target  location  to  gunships  (FIG  1-1).  One 
method  of  operation  was  for  the  scout  aircraft  to  drop  smoke  to  mark  a particular  target  for  the  gunship. 
Obviously  problems  such  as  wind  velocity  and  direction  which  are  uncontrollable  developed.  In  addition, 
the  enemy  also  knew  they  were  being  identified.  Another  method  of  operation  was  to  verbally  communicate 
target  information  via  the  aircraft  radios.  The  scout  commander  would  indicate '^here  is  a target  near 
the  crossing'' or" by  that  clearing, "etc.  The  gunship  would  then  have  to  try  and  find  the  target  after 
making  sure  of  the  verbal  transmission.  There  were  many  times  when  the  verbal  transmission  had  to  be 
repeated  several  times  (FIG  1-2).  He  had  time  to  fly  at  altitude  and  search  for  the  target.  In  future 
conflicts,  the  luxury  of  repeating  messages  and  flying  at  altitude  will  no  longer  be  available  because 
of  hostile  high  speed  detection  and  retalliation  capabilities.  A third  method  that  was  employed  in  the 
past  was  to  have  the  gunship  remain  at  a staging  area  (FIG  1-3).  The  scout  aircraft  would  then  locate  a 
target  and  fly  back  to  the  staging  area  and  lead  the  gunship  back  to  the  target  site.  Again  this  results 
in  excessive  aircraft  exposure  time  which  will  not  be  permissible  in  future  engagements. 

FIG  1-4.  The  critical  issues  in  any  future  combat  engagement  will  be  to  minimize  aircraft  exposure 
time  and  to  minimize  communication  time.  The  first  issue  will  be  resolved  by  flying  Nap-of-the-Earth  (NOE) 
taking  advantage  of  surrounding  terrain  such  as  masking  of  the  aircraft  by  a tree  line.  The  gunship  must 
receive  precise  coordinates  of  a target  (in  UTM)  from  the  scout.  This  means  more  sophisticated  navigation 
and  weaponry  systems  onboard  each  aircraft.  The  gunship  will  then  fly  NOE  to  the  target  coordinate,  pop-up 
and  fire.  There  will  no  longer  be  any  time  for  hovering  at  1000  feet  while  searching  for  the  target.  An 
exposure  exceeding  a brief  interval  of  time  could  mean  disaster. 

The  second  issue  of  minimizing  communication  time  will  be  accomplished  by  using  a fast  and  highly 
reliable  transmission  approach.  To  reduce  probability  of  intercept  by  hostile  forces,  a brief  data  trans- 
mission burst  must  be  used  to  reduce  communication  time.  The  use  of  error  detection  and  correction  coding 
will  enable  a high  reliability  of  successfully  transmitting  a message.  Using  digital  data  rather  than 
analog  voice  will  also  allow  an  effective  signal  to  noise  enhancement. 

2.  OBJECTIVE  (FIG  2-1) 


The  objective  of  the  Airborne  Data  Transfer  System  program  is  to  develop  an  advanced  technology  base 
(that  is,  subsystem  architecture,  interfaces,  trade-offs,  hardware  design,  feasibility  testing)  for  a 
data  information  handling,  handoff  and  transfer  subsystem  for  application  to  future  Army  aircraft  systems. 
The  first  application  would  be  for  a scout-gunship  target  handoff  scenario.  The  target  would  be  Identified 
by  a scout  aircraft  and  the  target  coordinates,  in  digital  UTM  format,  would  be  transmitted  via  aircraft 
radios  to  a gunship.  The  scout  would  either  have  a computer  which  assimulates  information  from  the  Doppler 
Navigation  System  and  Target  Acquisition  and  Designation  System  (TADS)  and  computes  the  UTM  target  coord- 
inates. Or  the  Data  Transfer  System  may  have  to  take  the  direct  inputs  from  the  Doppler  and  TADS  and 
compute  the  UTM  coordinates  Itself. 

The  Data  Transfer  System  would  then  incorporate  some  error  detection  and  correction  coding  to  assure 
high  reliability  of  sending  a message  to  reduce  the  probability  of  intercept  by  hostile  forces. 


The  Airborne  Data  Transfer  System  (ADTS)  program  is  a structured  effort  with  the  user  community  to 
develop  an  advanced  technology  base  for  inter-aircraft  and  aircraft  to  ground  data  handling.  The  system 
will  be  capable  of  transmitting/receiving  tactical  data  employing  data  enhancement  techniques  to  improve 
reliability  in  a Nap-of-the-Earth  (NOE)  operational  environment.  The  ADTS  will  be  a flexible  system  whose 
parameters  can  be  modified  per  user  preferences  or  per  operational  (testing)  experience.  Basically,  the 
ADTS  will  consist  of  a control  section,  a crew  input  keyboard  (CIK),  and  a display.  The  control  section 
is  broken  into  two  (2)  functional  areas:  control  of  communications  and  control  of  data  gathering  from 
onboard  subsystems.  The  data  and  control  input  keyboard  and  display  are  for  test  and  demonstration 
purposes.  In  a future  application,  existing  aircraft  keyboards  and  displays  will  be  used  if  at  all 
possible.  The  keyboard  is  for  operator  intervention  (what  type  of  target,  destination  of  message,  etc.) 
and  the  alpha-numeric  graphical  display  provides  visual  data  output  in  the  form  of  text,  prompting  messages, 
course  information,  and  display  of  spaclal  relationships  between  aircraft  and  targets. 


Various  functions  to  be  evaluated  using  the  ADTS  feasibility  models  are  data  rates,  formatting,  coding 
and  information  selection.  The  user  community  will  be  queried  as  to  what  types  of  information  would  be 
transmitted  in  various  aircraft  scenarios.  There  will  be  a capability  of  having  the  Commander's  (scout) 

ADTS  automatically  assigning  a particular  gunship  for  a particular  target  based  on  information  received 
from  each  gunship  as  to  position  location,  status,  weapon  capacity,  fuel  status,  etc.  It  could  have  a 
preprogrammed  scenario  which  selects  the  first  available  gunship  or  the  nearest  available  gunship,  etc. 

This  automatic  mode  could  be  overridden  by  the  crew  (manual  intervention) . Polling  of  the  status  of  various 
aircraft  could  be  done  manually  or  automatically. 

In  addition,  if  a scout  observed  a target  and  had  to  maintain  complete  silence,  he  could  go  back  to  the 
staging  area  to  give  the  information  to  a gunship.  He  could  also  give  him  check  point  information  to  enable 
the  gunship  to  fly  to  the  target  area  using  terrain  masking  following  the  nath  used  by  the  scout.  The 
display  would  present  such  check  point  information.  The  display  itself  will  be  evaluated  to  determine 
whether  alpha-numeric  and  graphical  capability  is  necessary  or  desirable.  Perhaps  the  need  for  only  alpha- 
numeric capability  will  result  from  the  ADTS  testing  phase. 

Also  to  be  investigated  is  the  use  of  various  aircraft  radios  for  target  handoff  application.  The 
VHF-FM  is  the  tactical  radio,  however,  it  might  be  feasible  to  use  either  the  VHF-AM  or  the  UHF-AM.  The 
flexibility  will  be  there  for  transmitting  on  a NOE  radio  whether  it  be  HF  or  a high  power  FM.  This 
would  be  most  useful  since  Line-of-Sight  FM/AM  radios  will  not  be  ideal  in  an  NOE  environment. 

The  ADTS  will  have  interchangeable  ports  so  that  by  merely  changing  cable  and  interface  card/module, 
a different  subsystem  can  be  interfaced.  Auxilliary  ports  will  also  be  available  for  any  future  subsystems. 

4.  HARDWARE  CONFIGURATION 

In  order  to  meet  present  and  anticipated  future  Army  requirements  it  was  determined  that  a flexible 
system  architecture  was  needed.  Because  future  aircraft  subsystems  cannot  be  completely  projected,  a 
means  of  interface  to  many  onboard  subsystems  must  be  available  which  require  minimal  impact  on  ADTS 
hardware  and  firmware.  The  following  architecture  was  chosen  which  will  meet  the  stated  flexibility 
requirements.  FIG  4-1  is  a basic  system  architecture  diagram  of  the  ADTS  as  it  is  envisioned  onboard  an 
attack  helicopter.  The  ADTS  processor  system  is  separated  into  two  functionally  separate  processing 
modules,  the  system  controller  module  (SCM)  and  the  transmit/receive  controller  module  (TRCM) . The 
The  SCM  is  the  main  processing  section  of  the  ADTS  in  that  all  routine  decision  making  algorithms  for 
pilot  unloading  reside  in  the  SCM.  The  SCM  coordinates  onboard  subsystem  data  and  prepares  it  for  trans- 
mission. In  the  case  of  the  attack  helicopter  this  data  may  come  from  the  crew  input  keyboard  (CIK) 
and  the  fire  control  computer.  In  aircraft  not  containing  a fire  control  number  (i.e.,  a scout  aircraft) 
this  same  data  would  come  from  the  CIK,  the  light-weight  Doppler  Navigation  System  (LDNS)  and  Target 
Acquisition  and  Designation  System  (TADS). 

The  data  received  from  these  various  subsystems  would  include  target  coordinates,  aircraft  position, 
target  priority,  target  identity  and  aircraft  status.  To  this  data  prestored  aircraft  source  identifi- 
cation and  destination  identification  would  be  added  to  form  a transmission  data  package.  In  the  case 
of  the  scout  aircraft,  aircraft  destination  identification  can  be  added  automatically  to  the  transmission 
package  from  internally  stored  data  regarding  available  attack  aircraft  (see  Section  6 regarding  Typical 
Scenarios) . The  ability  of  the  SCM  to  automatically  assign  target  information  to  an  available  attack 
aircraft  results  in  reduced  pilot  workload.  It  should  be  noted,  however,  that  all  automatic  functions 
of  the  SCM  can  be  overridden  by  the  pilot.  The  transmission  data  package  is  then  passed  to  the  TRCM. 

The  TRCM  is  responsible  for  all  operations  regarding  the  transmission  of  data  through  the  presently 
available  onboard  radio  links.  The  TRCM  obtains  from  the  transmission  data  package  the  destination  to 
which  the  data  is  to  be  sent.  The  ADTS  is  capable  of  transmitting  to  systems  which  incorporate  a differ- 
ent data  protocol  than  the  protocol  utilized  by  the  ADTS.  When  the  Army  standard  data  protocol  is  imple- 
mented the  ADTS  can  easily  be  reprogrammed  to  conform  to  the  standard  format.  Therefore,  from  the 
destination  information  the  TRCM  determines  the  appropriate  data  protocol  and  coding  format  to  convert 
the  transmission  data  package.  In  addition,  the  TRCM  selects  the  appropriate  data  rate,  between  37.5 
and  19. 2K  bits  per  second,  and  the  radio  subsystem.  After  transmission  the  TRCM  waits  for  an  acknowledgement. 
If  no  acknowledgement  is  received  after  a predetermined  time,  the  TRCM  will  repeat  the  message  for  a preset 
number  of  times.  If  no  acknowledgement  is  received,  the  TRCM  advises  the  SCM  of  its  inability  to  complete 
the  communications  link.  The  SC"  i.<  turn  advises  the  pilot  via  the  display  system. 

FIG  4-2  embodies  a more  detailed  schematic  of  the  ADTS  processor  system.  Both  the  SCM  and  the  TRCM 
contain  a separate  Input/output  processor  as  well  as  processor  augmentation  hardware. 
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The  SCM  I/O  processor  is  responsible  for  matching  the  bus  protocol  of  any  system,  up  to  eight,  interfaced 
through  one  of  the  eight  ports.  The  internal  I/O  bus  structure  allows  any  Interface  card  to  be  Interchanged 
into  any  other  SCM  1/0  port  and,  with  the  appropriate  external  cable  Interchange,  maintain  interface  operation. 
The  SCM  can  address  up  to  64  devices  with  8 control  functions  per  device.  This  permits  different  control 
scenarios  to  be  resident  in  the  SCM  processor  to  accommodate  all  envisioned  aircraft  configurations.  In 
this  manner  the  SCM  can  determine  its  subsystem  complement.  This  interface  structure  permits  the  SCM  to 
Interface  with  most  any  system  matching  that  system's  protocol  with  a minimum  of  Impact  on  ADTS  hardware 
and  firmware.  To  Interface  to  a given  subsystem,  a single  Interface  card  need  be  designed  and  the 
appropriate  software  handler  be  implemented  (see  Reprogramming).  Information  received  from  the  internal 
bus  N1  is  recognized  and  processed  by  the  SCM  I/O  processor  and  passed  to  the  SCM  main  processor  via  N2. 

The  SCM  main  processor  contains  the  decision  making  algorithms  in  addition  to  the  subsystem  data  processing 
algorithms.  The  SCM  main  processor  is  augmented  via  the  SCM  process  augmentation  module  which  provides 
multiply/divide  hardware  and  other  augmentations  which  boost  processing  speed.  The  SCM  forms  the  trans- 
mission data  package  and  passes  this  information  to  the  TRCM  via  bus  N4. 

The  TRCM  main  processor  contains  the  algorithms  necessary  to  identify  the  destination  and  select  the 
appropriate  data  protocol  and  code.  The  TRCM  also  contains  the  programming  for  data  rate  selection  and 
automatic  acknowledge  response  detection.  Once  a code  has  been  selected  (i.e.,  ADTS  code,  TACFIRE  code) 
the  TRCM  process  augmentation  module  codes  the  transmission  data  package.  The  transmission  data  package 
is  then  passed  to  the  TRCM  I/O  processor  for  transmission  over  the  selected  radio  link. 

The  TRCM  I/O  processor  contains  the  necessary  data  buffers  and  programmable  modem  for  data  transmission. 

The  TRCM  I/O  processor  selects  the  appropriate  onboard  subsystem  via  bus  N7  and  transmits  the  data  over 
the  same  bus.  The  TRCM  main  processor,  in  conjunction  with  the  TRCM  I/O  processor,  constantly  monitors 
the  radio  system  for  incoming  data.  If  a signal  is  determined  to  be  data,  the  TRCM  I/O  processor  squelches 
that  Information  from  the  pilot.  Before  a transmission  is  Initiated  the  TRCM  main  processor  determines 
whether  the  selected  radio  is  in  use  by  the  pilot.  If  the  pilot  is  using  the  radio,  the  TRCM  suspends 
its  transmission  until  that  radio  link  is  clear. 

It  is  not  the  primary  intention  of  the  ADTS  program  to  develop  a display  system  and  crew  input  keyboard. 
However,  to  evaluate  the  ADTS  various  display  formats  (to  include  alpha-numeric  and  graphics),  an  off-the- 
shelf  display  system  was  selected.  A multi-legend  programmable  keyboard  was  designed  to  provide  user 
input  to  the  ADTS  as  well  as  test  various  keyboard  function  configurations.  Display  and  keyboard  require- 
ments developed  from  this  program  will  be  available  for  incorporation  into  the  specification  of  a common 
aircraft  display  and  keyboard.  The  display  and  keyboard  specification  are  discussed  below. 

FIG  4-3  provides  a front  view  of  the  candidate  display.  The  dimensions  of  the  display  are:  height: 

3.8  inches;  width:  4.7  inches  providing  a usable  viewing  area  of  17.5  square  inches.  To  provide  display 
graphics  and  alpha-numerics,  an  off-the-shelf  graphic  processor  translator  was  selected  which  is  compati- 
ble with  the  selected  display.  The  graphics  processor  provides  up  to  2048  vectors  or  alpha-numerics. 

The  addressable  resolution  of  the  display  system  is  1000  x 1000  points.  The  graphics  processor  is  of 
the  random  scan  type  with  internal  display  refresh.  The  alpha-numerics  are  stored  within  a ROM  contained 
in  the  graphics  processor.  The  graphics  processor  can  provide  independent  fields  of  information,  up  to 
32,  to  permit  selected  field  modification  or  erase. 

FIG  4-4  provides  a front  view  of  the  candidate  keyboard.  The  dimensions  of  the  keyboard  are:  height: 

6 inches;  width:  4 inches.  The  keyboard  is  arranged  in  a matrix  of  4 x 4 modules.  Each  module  contains 
two  lines  of  four  characters  each  (upper  two  thirds  of  module)  and  a momentary  contact  switch  (lower  one 
third  of  module).  This  arrangement  permits  the  user  to  press  a given  switch  without  covering  the  display 
but  still  provides  a low  perception  error,  of  display  to  switch  relationship. 

The  eight  character  alpha-numeric  LED  display  arranged  in  two  lines  provides  a completely  flexible 
means  of  labeling  a given  switch  function.  This  display  method  also  permits  multi-level  switch  function 
indication  and  operation. 

ADTS  Reprogramming 

The  flexibility  of  the  ADTS  is  embodied  in  its  ability  to  be  reprogrammed  for  most  any  data  handling 
and  transmission  application  onboard  an  aircraft.  In  order  not  to  compromise  the  flexibility  of  the  system 
by  long  lead  time  reprogramming  requirements,  a means  of  reprogramming  the  ADTS  in-house  has  been  devised 
utilizing  an  existing  mini-computer  facility.  The  existing  mini-computer  will  have  resident  in  it  a 
cross  assembler  program  to  convert  ADTS  source  to  ADTS  object.  The  mini-computer  will  have  a loader 
verifier  program  to  program  PROMs  with  the  ADTS  object  code.  The  mini-computer  facility  consists  of  a 16 
bit  32K  mini-computer,  alpha-numerlc/graphlcal  display,  2.4M  word  disk  and  600  LPM  lineprinter.  In 
addition,  the  mini-computer  has  a powerful  editor  and  other  support  software  to  facilitate  reprogramming. 

All  ADTS  programs  will  reside  as  disk  files  on  the  mini-computer  for  rapid  recall  and  modification.  (FIG  4-5) 

In  field  use  maintenance  will  Include  replacing  PROM  cards.  At  depot  level  equipments  will  be  available 
to  transfer  digital  tape  master  contents  to  PROM  reprogrammers.  Preparation  of  digital  tape  masters 
will  be  performed  on  the  above  described  mini-computer  facility  by  the  R&D  Support  Command.  Mass  reprogramm- 
ing requirement  will  be  served  by  the  R&D  Support  Command  supplying  a digital  tape  master  to  a contractor 
for  mask  programmed  ROM's. 

5.  OTHER  APPLICATIONS 


In  addition  to  the  Target  Handoff  application  between  scout  and  gunship  aircraft,  other  possible 
applications  of  data  transfer  for  the  ADTS  are  conceivable.  One  such  application  is  the  MEDEVAC  mission 
using  UH-1  or  UTTAS  aircraft.  On  route  to  the  hospital  or  medical  facility,  it  is  conceivable  that  data 
on  the  patlent(s)  condition  could  be  forwarded  ahead.  Advice  on  how  to  handle  the  patient  enroute  or 
what  to  do  for  the  patient  could  be  received  from  the  hospital/medical  facility.  Short  digital  messages 
could  be  the  source  of  information  in  each  direction.  In  fact  some  preprogrammed  (canned)  messages  could 
be  stored.  Some  medical  devices  such  as  an  EKC  could  be  one  of  the  subsystem  inputs  to  the  ADTS. 


Another  possible  application  could  be  In  a NATO  type  environment.  Communications  betwen  various  NATO 
pilots/crews  could  be  achieved  by  having  preprogrammed  (canned)  messages  In  various  languages  aboard  an 
American  aircraft,  a German  aircraft,  a French  aircraft,  etc.  so  that  by  selecting  message  number  three 
(3), the  German  or  French  crew  would  generate  to  the  canned  message  In  their  own  language. 

In  future  applications,  an  In  Operation  System  Performance  Monitor  function  could  be  Incorporated 
wherein  various  aircraft  subsystems  Interfacing  with  the  ADTS  could  be  monitored  and  an  alert  message 
flashed  on  the  display  when  a malfunction  or  hazardous  situation  develops  such  as  loss  of  oil  pressure 
or  low  fuel  quantity,  etc.  This  can  be  done  If  Instruments  have  a digitized  output  to  the  ADTS.  A 
Lightweight  Doppler  Navigation  System  (LDNS)  has  its  own  self  test  or  built-in  test  feature  which  signals 
a fault.  This  signal  could  be  tied  Into  the  ADTS  which  would  alert  the  crew  via  the  display. 

Another  application  could  be  the  incorporation  of  various  terrain  profiles  in  the  ADTS  memory. 

This  could  be  useful  for  a pilot,  unfamiliar  with  the  territory,  to  make  an  approach  and  landing.  The 
terrain  profile  could  be  projected  on  the  display  to  assist  the  pilot. 

6.  TYPICAL  SCENARIO 


The  following  discourse  will  concern  the  ADTS  as  applied  to  a typical  attack  scenario.  It  should  be 
noted,  however,  that  the  tactical  position  presented  here  is  hypothetical  and  is  used  only  to  illustrate 
the  capabilities  of  the  ADTS  and  do  not  necessarily  represent  approved  tactical  maneuvers  of  the  US  Army. 

An  Attack  Team, comprising  four  (4)  attack  aircraft  and  two  (2)  scout  aircraft, is  located  in  LAGGER  area. 
Prior  to  take  off  the  aircraft  operators  initialize  their  respective  ADTS's  and  perform  the  system 
GO/NO-GO  tests  using  the  Built-In  Test  Equipment  (BITE) . The  test  results  are  maintained  in  the  form  of 
status  information  in  the  ADTS  for  periodic  maintenance  diagnostics.  Lead  scout  aircraft  polls  all  air- 
craft to  set  initial  aircraft  status  and  position.  As  all  aircraft  receive  the  response  to  the  scout 
aircraft  poll,  their  respective  ADTS's  are  correspondingly  updated.  The  In  Operation  System  / Performance 
Monitor  routine  (IOSPM)  is  initiated  to  continually  monitor  the  hardware  status  of  the  respective  aircraft 
subsystems  alerting  the  operator  of  any  system  failures. 

After  take  off  the  attack  aircraft  confirms  communication  links  and  proceeds  to  holding  position  B. 
Similarly  the  scout  aircraft  confirms  communication  links  and  proceeds  on  target  search  mission.  The 
scouts  are  guided  by  preliminary  reconnaissance  data  stored  in  their  respective  ADTS's  and  presented  as 
heading  and  distance  information  which  is  updated  as  the  ADTS  samples  data  from  the  onboard  navigation 
systems.  (FIG  6-1) 

Scout  aircraft  SH2  proceeds  to  position  C in  NOE  flight.  At  position  C SH2  unmasks,  sights  and 
designates  targets  with  Target  Acquisition  System. The  onboard  ADTS  samples  the  coordinate  output  of  the 
targeting  system  and  requests  target  priority  and  target  l.D.  from  operator.  SH2  remasks  and  the  operator 
complies  with  the  ADTS  request.  The  ADTS  displays  the  second  target  concentration  heading  and  distance 
information  and  SH2  proceeds  directly  to  the  position  as  it  is  near  his  present  location. 

SHI  has  reached  position  D,  the  target  concentration  of  potential  targets.  SHI  unmasks  and  acquires 
several  targets  with  the  onboard  target  acquisition  device.  After  remasking,  the  operator  complies  with 
the  requests  of  the  ADTS  to  enter  the  target  priorities  and  identifications  of  all  the  targets  previously 
designated  and  stored  automatically  by  the  ADTS.  SHI  proceeds  to  position  B to  disseminate  the  informa- 
tion to  the  available  attack  aircraft.  (FIG  6-2) 

While  SHI  is  enroute  to  position  B,  SH2  has  arrived  at  position  E,  designated  the  targets  at  that 
location,  entered  the  request  information  into  the  ADTS  and  proceeded  to  holding  position  F.  The  operator 
of  SH2  has  opted  to  indirectly  direct  the  attack  aircraft  to  the  various  stored  targets.  The  operator 
of  SH2  initiates  indirect  target  direction  mode  (ITDM)  of  the  ADTS  and  is  presented  with  a display  graph- 
ically indicating  the  locations  of  the  targets,  the  present  position  of  SH2  and  the  route  SH2  took 
from  the  LAAGER  area  to  position  F.  With  this  information,  the  SH2  operator  can  enter  on  the  ADTS  display 
the  most  direct  and  safest  course  for  the  attack  aircraft  to  follow  to  find  the  targets.  The  procedure 
takes  less  than  a minute.  SH2  initiates  an  update  transmission  request  to  position  B polling  all  attack 
aircraft  to  determine  their  position  and  status.  The  poll  reveals  that  all  aircraft  are  available.  The 
ADTS  automatically  makes  target  assignments  to  the  first  two  aircraft.  The  ADTS  then  automatically  trans- 
mits the  information  concerning  the  targets  (i.e.,  location,  priority,  identification)  and  the  necessary 
course  information  to  the  respective  attack  aircraft.  The  total  time  for  all  transmissions  will  be  less 
than  10  seconds. 

AH1  and  AH2  immediately  proceed  to  their  respective  targets  and  SH2  is  free  to  locate  other 
potential  targets.  (FIG  6-3) 

SHI  has  arrived  at  position  B to  directly  disseminate  its  target  information  to  the  remaining  attack 
aircraft.  As  SHI  proceeded  from  position  D to  position  B the  ADTS  has  sampled  the  onboard  navigation 
system  storing  checkpoint  information.  When  SHI  arrives  at  position  B,  the  target  Information  is  passed 
to  the  attack  aircraft  along  with  the  checkpoint  information  which  is  interpreted  by  the  attack  aircraft 
ADTS  and  presented  as  heading  information  in  reverse  order  to  the  attack  aircraft  operator.  AH3  and  AH4 
proceed,  following  the  course  information,  to  their  respective  targets.  (FIG  6-4) 

Tills  hypothetical  scenario  demonstrates  two  possible  means  of  disseminating  target  information  from 
scout  aircraft  to  attack  aircraft  utilizing  the  ADTS.  The  first  method  as  utilized  by  SHI,  is  the  direct 
target  direction  mode  (DTDM) . This  mode  required  SHI  to  fly  back  to  the  attack  aircraft  staging  area 
(position  B).  SHI  then  transmitted  the  target  information  along  with  the  return  course  information  sampled 
by  the  ADTS  from  the  navigation  system.  The  second  method,  the  indirect  target  direction  mode,  while 
retaining  the  capability  of  passing  target  course  following  information,  did  not  require  SH2  to  fly  back 
to  position  B.  Instead  the  SH2  coiranander  moved  to  a point  of  relative  safety,  entered  the  course  infor- 
mation utilizing  the  graphics  display  and  keyboard,  and  then  transmitted  this  information  to  the  attack 
aircraft.  Had  the  transmission  link  been  poor  SH2  could  have  gained  altitude  briefly  and  initiated  the 


short  (10  second)  transmission.  This  mode  of  operation  would  not  be  feasible  utilizing  conventional 
voice  transmission  means.  (FIG  6-5) 

7.  COMPUTER  SIMULATION 

When  new  systems  are  introduced,  it  is  frequently  difficult  to  determine  many  of  the  design  parameters 
in  advance  of  the  hardware.  For  the  purposes  of  writing  a statement  of  work  (SOW)  and  in  order  to  better 
evaluate  proposals,  preliminary  versions  of  ADTS  segments  were  simulated  utilizing  an  existing  interactive 
graphics  mini-computer  system  (see  FIG  4-5).  By  utilizing  the  graphics  of  the  mini-computer  system  an 
evaluation  of  information  could  be  made  to  determine  what  types  of  data  would  best  be  presented  graphi- 
cally (FIG  7-1).  In  order  to  size  the  proposed  ADTS  in  regard  to  processor  speed  and  memory  capacity, 
typical  ADTS  control  scenarios  were  programmed  into  the  mini-computer  system.  Linking  the  software  which 
controlled  the  alpha-numeric/graphical  information  with  the  ADTS  control  scenarios  yielded  a system  which 
could  simulate  the  ADTS.  Expanding  this  approach, three  autonomous  ADTS  control  scenarios,  two  simulating 
attack  aircraft  and  one  simulating  a scout  aircraft,  were  implemented  in  the  mini-computer  system  in  a 
multi-tasking  operation.  With  this  approach  the  operator  can  take  the  part  of  the  crew  of  either  aircraft 
and  interact  with  the  remaining  two  aircraft  simulating  a search  and  destroy  mission.  Because  each  aircraft 
control  scenario  is  a totally  separate  program  running  concurrently  with  the  other  programs,  any  one  can  be 
altered  or  modified  without  affecting  the  remaining  programs.  A means  was  developed  to  simulate  the  trans- 
mission of  data  between  aircraft  (control  scenarios).  As  in  real  system  operation  a transmission  directed 
to  one  aircraft  is  received  by  all  aircraft,  so  it  is  with  the  computer  simulation  of  the  three  ADTS's. 

If,  for  example,  the  scout  aircraft  initiates  a transmission  to  AH1,  AH2  also  receives  the  information, 
however,  only  AH1  responds  because  the  AH1  scenario  obtains  the  correct  destination  code  match.  AH2  also 
scans  the  destination  code  and  does  not  match,  however,  AH2  does  store  the  information  obtained  for  update 
purposes. 

Utilizing  the  mini-computer  in  this  manner  provides  a means  of  experimenting  with  possible  control 
scenarios  before  any  hardware  is  received  for  testing.  This  approach  will  also  shorten  the  experimentation 
required  using  the  actual  ADTS  hardware.  Information  and  scenario  flow  diagrams  derived  from  the  mini- 
computer system  can  be  directly  implemented  on  the  ADTS  when  it  becomes  available. 

As  the  ADTS  hardware  design  becomes  further  defined  the  mini-computer  simulation  will  be  modified  to 
provide  a more  accurate  representation  of  the  actual  system.  With  the  actual  configuration  of  the  display 
and  keyboard  determined,  the  simulation  is  now  being  modified  to  present  the  information  exactly  as  it 
would  appear  on  those  devices. 

This  paper  is  intended  as  in  introduction  to  the  ADTS  program.  Subsequent  papers  will  be  offered 
detailing  the  ADTS  hardware  when  it  becomes  available  and  the  results  of  the  ADTS  testing  program. 
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SUMMARY 

The  Precision  Location  Strike  System  (PLSS)  will  provide  the  battlefield  commander  with 
an  all-weather,  near- real- time , integrated  target  location  and  strike  capability.  To 
achieve  near- real- time  communications,  command,  control  and  intelligence  (C3I)  interface 
capability,  the  PLSS  is  being  developed  with  a Central  Processing  Communications  Element 
(CPCOM) . The  CPCOM  computer  automatically  processes  emitter  location,  tasking,  and 
weapon  delivery  data  into  formatted  messages,  which  are  distributed  over  appropriate 
AUTODIN,  TADIL-B,  teletype  and  485L  Digital  Data  Links. 

The  Air  Force  and  Arniy  C3I  organizations  in  the  theater  will  receive  PLSS  information 
which  supports  near- real- time : 

* tactical  control 

* air  surveillance  and  airspace  control 

* intelligence/fusion  functions 

The  CPCOM  is  architected  such  that  the  changing  theater  C3I  structures  and  message  stand- 
ards will  have  minimal  impact  on  the  other  PLSS  elements  and  can  be  easily  accommodated 
by  the  CPCOM.  In  addition,  the  CPCOM  will  have  data  transmission  filters  which  can  limit 
the  data  being  distributed  on  each  ground-to-ground  data  link  to  that  data  of  importance 
to  the  receiver.  This  filtering  scheme  will  also  be  used  to  limit  the  data  transmitted 
to  manual  facilities. 

The  PLSS  CPCOM's  full  capabilities  can  only  be  realized  when  other  theater  C3I  elements 
provide  automated  facilities  which  can  close  the  near- real- time  loop.  Until  that  time, 
the  PLSS  can  still  provide  valuable  information  to  manual  and  semi-automated  facilities. 

1 . INTRODUCTION 

1.1  Overview 

The  Precision  Location  Strike  System  (PLSS)  will  provide  the  tactical  battlefield  commander 
with  an  all-weather,  near- real- time , integrated  target  location  and  strike  system.  This 
capability  will  revolutionize  tactical  conventional  warfare  concepts  of  operation  in  the 
1980s  and  beyond  by  providing  the  battlefield  commander,  operations,  and  intelligence 
facilities  with  virtually  instantaneous  information  on  battlefield  developments.  The  PLSS 
system  is  being  developed  to  operate  in  the  dense  electro-magnetic  environment  expected 
during  the  mid-1980s  in  the  European  area  and  with  the  mobility  to  deploy  to  other  areas 
of  the  world. 

1.2  PLSS  Elements 

The  system  consists  of  intercept/relay  aircraft,  attack  aircraft  carrying  unguided  or 
stand-off  guided  ordnance,  a ground  computer  facility  and  ground  navigation  beacons.  All 
of  these  elements  are  connected  by  data  links  over  which  the  necessary  navigation,  loca- 
tion and  weapons  commands  are  passed  among  the  PLSS  system  element^.  In  addition,  input/ 
output  of  PLSS  communication,  command,  control  and  intelligence  (C^I)  data  will  occur  in 
near-real-time  with  other  battlefield  systems. 

2.  CONCEPT 

2.1  Intercept 

A 

The  PLSS  concept  involves  the  detection  of  enemy  electronic  emissions  by  the  PLSS  inter- 
cept/relay aircraft.  The  detected  emissions  are  pre-processed  by  the  on-board  equipment 
and  relayed  to  the  PLSS  ground  computer  facility.  Within  the  computer  facility,  the 
precise  position  of  detected  emitters  is  calculated  within  the  PLSS  grid  system.  The 
detected  emitter  location  data  is  passed  to  the  communications  element  for  forwarding  to 
other  battlefield  systems  for  a decision  on  attacking  the  target  and  for  intelligence 
functions.  The  PLSS  contains  software  to  convert  the  PLSS  grid  system  to  Geodetic 
(Latitude/Longitude)  or  Universal  Transverse  Mercator  Coordinate  systems. 

2.2  Location 

The  precise  location  of  a PLSS  detected  target  relies  on  precise  location  of  the  PLSS 
intercept/relay  aircraft.  The  aircraft  continuously  interrogate  ground  navigation 
beacons  and  relay  the  distance  measuring  equipment  responses  to  the  computer  facility 
for  processing  and  calculation  of  precise  location  of  the  aircraft.  The  position  of  the 
intercept/relay  aircraft  provides  the  basis  for  determining  the  position  of  the  emitters 
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and  attack  aircraft/weapons. 

2.3  Strike 

PLSS-associated  attack  aircraft  will  carry  either  conventional  stand-off  guided 
weapons  or  conventional  unguided  weapons.  The  attack  aircraft  will  receive  guidance 
commands  to  a release  basket  in  the  case  of  guided  weapons  aircraft  or  to  a precise 
release  point  for  unguided  weapons  aircraft.  Guided  weapons  commands  are  relayed 
through  the  intercept/relay  aircraft  after  release  until  weapon  impact.  In  the  case 
of  unguided  weapons,  the  PLSS  computer  facility  actually  commands  the  release  to  obtain 
the  required  weapons  accuracy. 

2.4  Targets 

Targets  for  PLSS  attack  can  be  provided  by  the  PLSS  emitter  location  function  or  can  be 
inserted  into  the  PLSS  computer  if  targets  are  designated  from  external  sources.  The 
only  limitation  to  external  targeting  is  that  the  targets  must  be  designated  with  suffi- 
cient accuracy  for  a PLSS  weapon  attack  to  achieve  the  desired  probability  of  kill. 

2.5  Information  Distribution 

The  types  of  information  sent  to  various  battlefield  organizations  from  the  PLSS  ground 
computer  facility  are  tactical  control  and  tasking,  air  surveillance  and  airspace  control, 
and  data  to  support  intelligence/fusion  activities.  The  full  utilization  of  the  PLSS 
capability  to  provide  and  receive  near-real- time  data  for  tactical  applications  is 
directly  related  to  the  capability  of  the  interfacing  battlefield  systems'  automated 
capabilities  for  processing  this  data.  The  handling  of  this  data  on  the  PLSS  side  of  the 
interface  is  the  topic  of  this  paper.  Figure  1 depicts  the  elements  of  the  PLSS. 

3.  CENTRAL  PROCESSING  COMMUNICATIONS  ELEMENT  (CPCOM) 

3.1  Description 

The  CPCOM  is  one  portion  of  the  PLSS  ground  computer  facility  and  contains  all  of  the 
equipment  for  voice  and  data  communications  with  the  battlefield  agencies  external  to 
the  PLSS  system.  The  CPCOM  consists  of  an  AN/UYK-25  computer,  interfaces  to  the  naviga- 
tion and  location  computers,  modems,  encryption  equipment,  wirelines,  UHF  and  HF  radios. 

Data  is  passed  among  battlefield  components  and  PLSS  in  near- real- time  to  support  tactical 
control,  air  surveillance  and  airspace  control,  intelligence  and  fusion.  There  are 
various  other  types  of  information  which  are  passed  infrequently  or  on  a scheduled  basis, 
but  due  to  its  non-near- real- time  nature,  is  considered  outside  of  the  scope  of  this 
paper. 

3.2  Interface  Definition 

The  actual  CPCOM  data  interface  functions  are  being  examined  in  terms  of  nine  layers  of 
interface  definition: 

a.  Media  Identification 

Defines  the  specific  data  communications  media  including  the  number  of  paths 

and  options. 

b.  Media  Hardware 

Defines  the  signal  level,  wave  forms,  signal  duration,  interval  synchroniza- 
tion, character  codes,  etc.  for  each  media. 

c.  Transmission  Media  Structure 

Defines  the  block  sizes,  framing  control,  error  detection/correction,  etc.  for 

each  media. 


d.  Transmission  Media  Handling 

Defines  the  content  and  format  of  message  headings,  endings,  and  communica- 
tions messages  for  each  media. 


e.  Information  System  Handling 


Defines  the  format  and  ordering  of  message  identity  description  information, 
methodology  for  transmission  of  data  elements  and  their  interrelationships,  methodology 
for  relating  data  elements  to  the  recipients'  information  system  structure  and  permissible 
transaction  instructions.  These  procedures  are  not  unique  to  each  media. 


Information  System  Message  Content 


Defines  the  messages  available,  including  formats,  data  elements,  hierarchy, 
number  of  occurrences,  order  and  conditions  of  use.  These  procedures  are  normally,  but 
not  necessarily,  related  to  a particular  information  system  and  are  not  related  to  one 
media. 


30-3 


g.  Data  Elements 

Defines  the  data  characteristics,  codes,  meaning  and  uses  of  individual  data 
elements  found  in  the  message  formats  identified  and  controlled  in  Layer  f.  They  should 
not  be  related  to  one  media  or  information  system. 

h.  Information  Conveyance  Requirements 

Arbitrarily  divides  a mission  into  discrete  activities  and  describes  the 
conditions  and  events  requiring  transmission  of  formatted  data  to  specified  recipients. 

i.  Environment 

Defines  the  availability  and  capability  of  battlefield  entities  and  the 
communications  media  that  connect  the  entities  to  the  PLSS. 

Each  layer  of  the  interface  definition  process  is  necessary  for  automated 
data  handling.  This  process  is  extremely  difficult  and  time-consuming  and  further  com- 
plicated by  the  requirement  for  PLSS  to  be  capable  of  operating  in  any  theater.  In 
addition,  many  of  the  battlefield  systems'  data  handling  techniques,  messages,  hardware 
and  even  the  media  are  not  fully  defined  at  this  time  due  to  the  relatively  recent 
interest  in  near-real -time  data  exchange  for  the  tactical  battlefield. 

3.3  Flexibility 

The  PLSS  CPCOM  is  structured  so  that  hardware  and  software  changes  due  to  changes  in 
transmission  media,  protocols,  message  standards,  etc.  will  not  impact  the  navigation  and 
location  computers  also  within  the  PLSS  ground  computer  facility  complex.  This  is  accom- 
plished by  rigorously  defining  the  data  elements  which  are  to  be  passed  between  the 
CPCOM  and  the  location  and  navigation  computers.  The  processing  software  in  the  CPCOM  is 
modularized  to  allow  minimum  impact  when  changes  are  identified.  In  addition,  careful 
selection  of  "off-the-shelf"  modems  and  line  control  function  hardware  will  lessen  change 
impacts  to  hardware  by  selecting  multiple  media  line  controllers  and  modems.  As  the 
definition  of  joint  US  message  standard  proceeds  and  eventually  merges  with  NATO  require- 
ments, software  and  hardware  changes  will  be  accomplished  with  minimum  impact. 

3.4  Data  Filtering 

A data  transmission  filtering  capability  will  be  incorporated  into  the  CPCOM  to  assure 
the  receiving  battlefield  system  receives  only  the  information  for  which  it  has  a near- 
real-time  need.  Emitter  data  will  be  compared  to  a table  of  known  emitters  and  if  the 
emitter  has  been  previously  reported,  the  emitter  data  will  not  be  sent.  In  addition, 
each  receiver  of  PLSS  emitter  data  can  specify  geographic  areas  and  types  of  emitters 
for  which  he  wishes  to  receive  data.  The  filters  for  each  PLSS  output  link  are  updated 
prior  to  a mission  and  may  be  changed  during  the  mission  to  reflect  changing  battlefield 
interests.  This  filter  capability  reduces  the  output  link  loading  and  reduces  the  amount 
of  data  each  recipient  must  handle  and/or  process.  In  addition,  PLSS  will  probably  be 
deployed  before  many  of  the  battlefield  systems  have  automated  processing  and  handling 
capability  for  incoming  PLSS  information.  The  filter  capability  will  allow  these  manual 
or  semi -automated  facilities  to  prioritize  data  needs  and  receive  only  the  data  reflecting 
their  need  prioritization. 

3.5  Transmission  Media 

The  requirement  to  communicate  in  near- real  - time  with  many  types  of  battlefield  components 
in  any  theater  of  operation  has  resulted  in  four  transmission  media  which  have  differing 
protocols,  message  standards  and  associated  hardware.  The  transmission  media  planned  for 
incorporation  are  AUTODIN,  48SL  Digital  Data  Link  (DDL),  TADIL-B  and  Teletype.  These 
four  media  will  allow  PLSS  near- real  - tin  e communication  with  the  appropriate  battlefield 
facilities  in  any  conceivable  theater  of  operation.  Figure  2 indicates  the  general 
messages  and  media  requirements  for  PLSS  near- real  - time  data  communications  and  Figure  3 
shows  the  general  data  handling  capabilities. 

3.6  Problems 

There  are  many  problems  associated  with  developing  a multi-media  data  distribution  cap- 
ability. The  most  significant  problem  is  the  evolutionary  process  of  developing  message 
standards.  The  PLSS  CPCOM  is  being  developed  to  adapt  to  accepted  message  standards. 
However,  in  several  cases,  the  standards  are  of  an  interim  nature  and  change  rapidly. 

It  is  difficult  to  adapt  rapidly  enough  to  these  changing  requirements.  In  addition,  in 
some  cases  the  message  standards  have  not  been  suitable  for  passing  PLSS  data.  Requests 
for  changes  to  fully  established  message  standards  can  easily  take  one  to  two  years  to 
resolve  and  be  reflected  in  the  media  documentation  and  hardware. 

In  addition,  the  development  of  unique  national  data  communication  capabilities  impedes 
the  multi-national  information  exchange  essential  for  battlefield  command  and  control  in 
the  European  theater.  However,  as  NATO  tactical  data  communications  systems  are  estab- 
lished, the  inherent  flexibility  of  PLSS  hardware  and  software  will  permit  the  change- 
over with  minimum  impact.  A NATO  tactical  data  communications  system  will  have  to  provide 
not  only  the  hardware  for  transmission  media,  but  the  message  standards  to  allow  auto- 
mated processing  on  both  sides  of  the  interfaces.  In  addition,  there  must  be  provision 
for  non-automated  facilities.  The  rigorous  formatting  requirements  required  for  automated 
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data  handling  can  be  a barrier  to  non-autt>mated  data  handling  due  to  the  human  error 
factor. 


4.  CONCLUSION 

The  development  of  automated  data  handling  systems  to  provide  near- real - time  data  to  the 
tactical  battlefield  users  requires  a systematic  interface  layer  definition  process. 
However,  due  to  the  rapid  changes  in  the  message  standards,  media  requirements  and  lack 
of  NATO-wide  standards,  the  flexibility  to  alter  system  hardware  and  software  must  be 
possible  with  minimum  system  impact.  Partitioning  of  the  data  communications  systems 
from  other  automated  capabilities  and  filtering  transmission  data  to  reduce  the  media 
loading  and  processing  can  aid  in  the  system  development. 
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Fig.  1 Precision  location  strike  system 
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Fig.2  PLSS  near-real-time  data  matrix. 

Note  that  not  all  media  will  be  used  in  any  theater  and  not  all 
information  is  required  in  near-real-time  in  all  system  deployment  concepts 
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SUMMARY 

MSI-fcOS  is  the  name  of  an  Integrated  Fire  Control  System  developed  for  Fast  Patrol  Boats  in  the  Royal 
Norwegian  Navy.  The  paper  deals  with  the  specific  threat,  the  philosophy  behind  the  operational  aspects 
and  the  system  description  of  the  fire  control  system.  The  results  given  are  based  upon  the  technical 
evaluation  of  the  prototype  aboard  KNM  "HAUK"  autumn  1977. 


1.  INTRODUCTION 

The  Royal  Norwegian  Navy  (RNON)  have  a vast  experience  using  Fast  Patrol  Boats  (FPB)  since  World  War  II. 
Based  upon  this  experience  and  the  results  from  the  development  of  a new  fire  control  system  for  the 
RNON  submarines,  the  requirement  for  the  new  FPB-class  was  established  in  the  early  seventies.  These  new 
FPB's  were  named  HAUK  (HAWK)-c1ass. 


2.  THREAT 

The  geographical  position  of  Norway  is  shown  on  this  map.  (Fig.  1).  Keypoints  here  are,  starting  from 
the  north: 


o A border  to  Russia 

o A long  coastline  towards  the  Barents  Sea  and  the  North  Sea 

Adjacent  to  the  Norwegian  border  is  the  KOLA  peninsula  where  the  Soviet  Union  has  the  biggest  combined 
base-system  in  the  world.  The  icefree  distance  from  the  Soviet  Union's  bases  to  the  Norwegian  border  is 
about  100  km. 

The  Russian  Northern  Fleet  is  the  Soviet  Union's  largest  maritime  force  of  which  their  submarines  with 
ballistic  missiles  represent  the  biggest  threat  to  the  NATO-countries.  Most  of  these  submarines  operate 
from  the  bases  in  KOLA. 

The  North  Sea  is,  from  a military  point  of  view,  of  equal  importance  due  to  the  fact  that  it  is  the  end 
point  for  the  reinforcement  and  supply  lines  to  central  Europe;  it  contains  the  main  routes  for  NATO 
reinforcement  from  Britain  to  Denmark,  and  it  is  essential  that  NATO  has  control  of  this  area  to  prevent 
the  enemy  from  breaking  through  into  the  Atlantic. 


In  order  to  secure  a free  passage  for  the  Russian  Northern  Fleet  from  the  KOLA  bases  and  the  Red  Banner 
Fleet  operating  in  the  Baltic,  Soviet  Union  control  of  Norwegian  stategic  harbours  is  of  vital  interest. 
Since  those  areas  play  such  an  important  role  for  the  Soviet  Union  and  the  Warsaw  Pact,  it  is  of  equal 
importance  to  NATO.  One  of  the  main  tasks  of  the  RNON  is  therefore  to  stop  an  invasion. 


The  length  of  Norway  to  defend  is  large  (about  1100  miles),  the  coastline  with  fjords  etc.  is  about  15 
times  that  distance.  The  coast  is  scattered  with  islands,  and  the  water  is  shallow  which  puts  great 
demands  on  knowledge  concerning  local  conditions  when  operating  in  these  waters. 

In  a few  words  the  battle  area  is  well  suited  for  hit  and  run  tactics.  This  is  the  basic  idea  of  using 
small  fast  boats  equipped  with  offensive  weapons  under  the  command  of  a crew  drilled  to  operate  in  this 
environment.  The  success  of  FPB  operations  depends  heavily  on  the  vessels  ability  to  be  at  the  right 
place  at  the  right  time,  and  their  ability  to  launch  the  weapons  against  the  enemy  without  being 
detected.  This  can  only  be  achieved  by  the  right  combination  of  tactics  and  equipment,  where  the  Weapon 
Control  System  plays  a major  role. 


PH  I L0S0PHY  BEHIND  OPERATIONAL  REQUIREMENT 


A powerful  ECM  resistant  Fire  Control  R.  Jar  is  not  only  suceptible  to  early  intercept  and  identifi- 
cation, but  is  also  vulnerable  to  enemy  Electronic  War-fare,  like  for  instance  use  of  "chaff"  and 
"decoys". 
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In  order  that  the  FPB  can  remain  undetected,  it  is  required  that  target  detection,  identification,  and 
tracking  can  be  achieved  by  passive  means.  This  led  to  a sensor  concept  where  the  expensive  and  powerful 
ECM  resistant  Fire  Control  Radar  was  substituted  by  a commercial  high  quality  navigation  radar  with 
satisfactory  accuracy  and  range,  complemented  by  a set  of  electro-optical  sensors  like  Low-Light  TV 
(LLTV),  Infrared  (IR)  vision  and  Laser  Range  Finder  (LRF).  These  sensors  provide  considerable  ECCM 
capability,  target  detection,  and  passive  tracking  together  with  night  vision  for  identification  and 
navigation  in  narrow  waters. 

The  expenses  saved  on  the  Fire  Control  Radar  were  sufficient  to  finance  the  electro-optical  sensors. 

The  other  important  consideration  was  the  comnand  and  control.  The  introduction  of  wire-guided  torpedoes 
and  Penguin  SSM  requires  equipment  to  ensure  co-ordinated  deployment  and  target  allocation  within  the 
FPB  divisions.  This  requires  automatic  data  processing  with  an  adequate  number  of  displays. 

This  lead  to  the  MSI-80S  (Multi  Sensor  Integrated  Control  System  for  the  80s  Surface).  The  evaluation 
model  was  delivered  early  1977,  and  went  through  a technical  evaluation  autumn  1977  aboard  the  prototype 
of  the  "HAUK"-class  FPB.  The  first  operational  system  will  be  delivered  mid  summer  1978.  Main  data  for 
"HAUK"  is  given  in  appendix  1. 
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4.  SYSTEM  CONFIGURATION 

Figure  2 shows  the  system  configuration.  The  weapons  to  be  controlled  are  2 wire  guided  torpedoes,  6 
Penguin  Ship  to  Ship  Missiles  (SSM),  and  one  40  mm  L70  gun. 

The  sensors  are: 

o The  electro-optical  system,  consisting  of  a Low-Light-TV-System,  a Laser  Range  Finder  and  an 
Infrared  vision  System. 

o The  radar  system:  Consisting  of  2 radars 

o The  TV-tracker  system,  which  is  an  autonomous  system  designated  to  the  L70  gun. 

The  data  processing  distribution  and  presentation  is  controlled  by  a highly  integrated  3 operator's 
console. 


o Tactical  Operator 

o Weapon  Operator  •, 

o Passive  Sensor  Operator 

The  commanding  officer's  place  is  in  front  of  the  operators  console.  At  this  position  he  will  have  all 
the  information  he  needs  in  one  glance.  At  the  same  time  he  maintains  quick  reaction  and  control  of 
weapons,  together  with  the  position  of  hostile  and  friendly  units. 

The  next  chapter  describes  the  different  subsystems  in  more  detail.  Special  emphasize  is  put  on 
handling,  integration  and  presentation  of  the  data.  The  main  specifications  of  the  equipment  are  given 
in  appendix  2. 


5.  DESCRIPTION  OF  SUBSYSTEM 


5.1  Radar  System. 

The  data  for  command,  control  and  weapon  delivery  is  provided  from  a variety  of  sensors  of  which  the 
radar  system  is  the  only  all  weather  sensor.  The  system  selected  consists  of  two  conrnercial  Decca  1226 
navigation  radars.  The  use  of  one  6 ft  and  one  9 ft  antenna  with  special  interswitching  between  3 
transceivers  gives  a high  degree  of  flexibility  and  provides  some  ECCM.  The  9 ft  antenna  and  its  two 
transceivers  are  coupled  so  as  to  serve  as  primary  radar  for  MSI-80S  while  the  6ft  antenna  and  its 
transceivers  are  referred  to  as  the  navigation  radar,  though  fully  integrated  in  the  MSI-80S. 

Automatic  radar  extraction  of  targets  combined  with  Kalmanf i 1 tered  data  processing  provide  required 
accuracy  for  the  control  of  the  torpedoes  and  the  Penguin  missiles  with  the  latter's  variable  geometric 
flight-path. 
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5.2  Electro-optical  System. 

The  original  electro-optical  sensor  concept  was  based  upon  the  implementation  of  IR-vision  (thermal 
imagers,  FLIR)  complemented  by  a modest  LLTV  system  for  passive  detection,  identification  and  target 
tracking  during  day  and  night  operations.  After  concluding  an  extensive  market  survey  it  was  decided  to 
postpone  the  integration  of  IR-vision  in  this  project  for  the  time  being.  The  electro-optical  platform 
is,  however,  prepared  to  accept  an  IR-sensor  whenever  the  Navy  finds  it  cost-effective. 


Instead  the  decision  was  made  to  use  an  IS  I T LLTV  system  which  gives  required  night  vision  to  10*3  lux 
(starlight  capability).  Improved  camera  tubes  and  automatic  iris  control  greatly  reduce  the  blooming 
effect  of  the  LLTV  system,  while  retaining  a favourable  light  sensitivity  and  S/N  ratio. 
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The  other  elector-optical  sensor  used  is  an  L.M.  Ericsson  sea  target  laser  range  finder  collimated  to 
the  LLTV  system.  By  placing  the  trigger  and  receiver  units  in  closed  environment,  a high  degree  of 
electronic  interference  protection  has  been  achieved.  Attenuation  filters  are  used  to  provide  peace 
time  training  without  hazardous  risks  to  implicated  personnel. 


5.3  Stabilized  Platform. 

The  electro-optical  sensors  are  mounted  on  a three  axis  specially  designed  stabilized  platform  giving 
true  horizon  positioning  of  the  sensors.  The  stabilizing  element  is  an  integral  part  of  the  platform, 
weather  protection  being  achieved  by  a half  dome  construction.  Signal  transfer  is  by  sliprings  and  the 
platform  is  prepared  for  mounting  additional  sensors. 

In  addition  to  stabilize  the  E/O-sensors  the  platform  gives  data  of  the  roll  and  pitch  movement  of  the 
ship  to  the  various  users  together  with  the  ship  attitude  data  for  weapon  control.  The  key  elements  in 
the  stabilized  platform  are  2 gyros,  2 accelerometers  and  a microprosessor.  By  using  a velocity  input 
from  a log  (accuracy  < 0,5  knots)  the  microprosessor  also  generates  own  ships  data  in  absolute 
geographical  co-ordinates. 


5.4  TV-Tracker  System. 

The  40  mm  L70  is  primarily  for  air  defence  and  will  he  controlled  by  an  autonomous  unit  - a TV 
Tracker.  The  TV  camera  head  is  manually  brought  into  vicinity  of  the  target,  after  which  the  TV 
operator  locks  on  the  target  by  means  of  his  monitor  and  joystick.  The  TV  tracker  then  automatically 
tracks  the  target  and  controls  the  gun's  bearing  and  elevation. 

The  weapon  operator  can,  however,  designate  targets  to  the  TV  tracker  system  by  means  of  a special 
target  designation  unit  which  provides  the  TV  tracker  system  monitor  with  target  range  and  bearing. 
Features  for  automatic  slaving  of  the  electro-optical  package  on  the  platform  to  the  TV  tracker 
azimuth  bearing  are  also  provided. 

On  the  stabilized  tracker  a small  Radar  Search  Receiver  (RSR),  is  mounted,  and  hence  a limited  remote 
control  is  thereby  provided.  The  radar  search  receiver  can  by  a handgrip  be  removed  and  interchanged 
with  a binocular  if  a conventional  optical  sighting  is  required. 


5.5  Automatic  Data  Processing. 

The  information  obtained  Dy  the  sensors  is  integrated  and  processed  by  the  SM3  16  bit  general  purpose 
computer  located  in  the  operators  console.  The  computer  has  a 48  K memory  of  which  32  K is  used.  This 
computer  is  already  used  in  the  NATO  Sea  Sparrow  systems.  The  computer  can  process  target  data  for 
automatic  plotting.  The  data  is  based  on  inputs  from  an  automatic  radar  extractor,  passive  sensors  and 
the  laser  range  finder,  or  manually  injected  target  data. 
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5.6  Operators  Console. 

The  processing  of  data,  distribution,  and  presentation  is  controlled  by  means  of  a highly  integrated 
operators  console,  Fig.  3.  The  main  parts  of  the  console  consist  of: 

23  inch  Tactical  Display 

12  inch  Data  Display 

Tactical  Operators  Panel 

Weapon  Control  Operators  Panel 

Passive  Sensor  Control  Panel 

The  23  inch  tactical  CRT  display  for  presentation  of  raw  radar  video  and  computer  generated  synthetic 
information,  includes  all  normal  radar  display  features  including  true  motion  and  five  range  scales 
from  3 to  48  f*n,  Fig.  4. 

By  addition  the  following  special  features  are  to  be  mentioned: 

Display  of  target  number  with  predicted  target  course  and  speed  vectors  for  selected  targets. 

Own  ship  position  history 
Bearing  from  passive  sensors 


L_ 


3M 


- Laser  range  presentation 
Ten  reference  points 

Calculator  functions  concerned  with  time,  speed  and  distance  parameters 
Torpedo  and  missile  attack  solutions 
Torpedo  predicted  course  and  position 
Missile  predicted  flight-path  and  position. 

The  12  inch  data  display  presents  all  necessary  "Command"  data.  The  most  Important  information  is  the 
Common  Cartesian  Grid  (CCG)-target  data,  Fig.  5,  containing  target  designators,  target  number,  time, 
common  CCG  co-ordinates,  course  and  speed,  ships  allocated  to  the  target  and  own  weapons  designations  for 
targets.  A similar  data  tabular  can  be  presented  referenced  to  range  and  bearing  from  own  ship. 

Other  presentations  selected  by  the  command  are: 

Missile  data 

Torpedo  data 

Attack  position  data.  Fig.  6 

Priority  can  be  given  to  two  tracked  targets  whose  data  is  always  presented  irrespective  of  vrfiat  data 
presentation  is  selected. 

The  presented  data  is  digitalized  thus  easily  enabling  data  link  transmissions  to  own  forces.  The 
received  transmissions  may  then  be  presented  on  the  data  display  in  the  co-operating  ships.  For 
automatic  data  transfer  a 75  bd  data  link  is  considered  sufficient.  Both  the  MSI-80S  and  the 
communication  equipment  are  prepared  for  such  a link,  but  the  matter  of  link  compatibility  has  deferred 
the  decision  on  link  implementation. 

Information  can  be  switched  between  the  12  inch  data  display  and  the  23  inch  tactical  display  and  vice 
versa  in  case  one  of  them  fails. 


5.7  Main  Tasks  for  the  Operators. 

THE  TACTICAL  OPERATOR  initiates  the  target  data  computations  and  has  control  of  the  tactical  display. 

Main  modus  for  track  initiation  is  a manual  tracking  ball  function.  The  target  number  designation  is 
keyed  in  by  the  operator. 

There  are,  however,  various  other  schemes  to  initiate  targets  for  example  initiation  of  target  data 
computations  by  means  of  CCG  coordinates  received  from  external  sources. 

THE  WEAPON  OPERATOR  selects  the  various  control  modes  for  the  weapons  and  sets  up  and  controls  the 
weapon  salvos.  Two  torpedoes  against  two  separate  targets  can  be  controlled,  while  at  the  same  time  a 
Penguin  SSM  salvo  can  be  launched  against  a third  target  or  one  of  the  targets  engaged  by  the  torpedoes. 
The  operator  can  choose  between  straight  or  angular  flight-path  for  the  Penguin  missiles,  and  manual 
line  of  sight  or  collision  point  guidance  modes  for  the  torpedoes.  Weapon-to-target  designation  is 
target  number  initiated  after  which  all  relevant  weapon  data  is  processed  and  distributed  to  the  weapon 
to  be  used. 

The  weapon  operator  has  for  this  purpose  the  following  weapon  data  sections  at  his  disposal: 

Weapon  selector 
Weapon  control 
Weapon  fire  section 
Emergency  mode 

THE  PASSIVE  SENSOR  OPERATOR  controls  the  passive  sensors  together  with  the  laser  range  finder.  On  his 
request,  sensor  observations  are  automatically  transferred  to  the  computer  for  further  processing  and 
integration.  The  stabilized  platform,  on  which  the  LLTV  and  laser  range  finder  is  mounted,  can  be  either 
automatically  or  manually  slewed  for  target  aquisition.  If  a target  bearing  is  already  known  from  the 
presentation  on  the  tactical  display,  the  sensor  platform  can  be  trained  directly  to  this  bearing.  Once 
the  angular  movement  of  a target  has  been  computed,  rate  aided  tracking  can  be  performed.  Fine 
adjustments  to  keep  the  sensors  dead  on  the  target  will  normally  have  to  be  done  manually  by  the 
operator  while  watching  the  IV  picture  on  the  monitor  in  front  of  him. 


The  laser  range  finder  is  manually  fired.  Three  ranges  on  the  same  bearing  are  presented,  one  range 
selected  by  the  operator  might  be  transferred  to  the  system. 


The  platform  bearing  and  laser  range  is  either  automatically,  or  manually  transferred  to  the  computer. 
Provision  is  made  for  fast  “swapping"  between  two  selected  or  priority  targets. 

The  monitor  and  joystick  for  the  TV-tracker  system  is  placed  adjacent  to  the  passive  sensor  operator. 
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The  bearing  from  the  TV  tracker  may,  however,  be  transferred  to  the  computer,  and  the  TV  video  can  be 
displayed  on  the  passive  sensor  operators  TV  monitor,  thus  providing  an  additional  sensor  mode  for  weapon 
control . 

Radar  Search  Receiver  intercepts  are  analyzed  by  means  of  an  analyzing  unit  on  the  passive  sensor  panel. 


5.8  Training  and  Recording. 

Training  facilities  are  incorporated  into  the  system  which  allow  simulation  of  certain  vital  functions. 
These  simulations  are  initiated  by  manual  operations  from  the  control  panels. 

Own  ship's  movement  is  simulated  by  manual  settings  replacing  the  log  and  gyro  compass. 

Eight  ficitious  radar  echoes  serving  as  targets  can  be  generated  and  tracked. 

Simulated  missile  and  torpedo  firings  are  performed  by  switching  the  weapon  systems  into  a simu- 
lated mode. 

A dual  cassette  recorder  is  built  into  the  console.  This  is  used  for  programme  loading  and  data 
recording.  The  recordings  will  contain  the  following  data: 

Own  ship's  movement 

Sensor  observations 

Tracking  solutions 

Weapon  data 

Geographical  positions 

For  a quick  review  of  events  and  for  debriefing  purposes,  a separate  system  programme  provides  replay 
facilities  on  the  console.  Own  ship,  missile  flight-paths  and  torpedo  courses  are  then  drawn  on  the 
tactical  display.  Replay  of  the  recordings  are  also  performed  on  shore  based  trainers  for  tactical 
evaluation  and  more  profound  analysis. 

The  replay  system  aboard  can  be  extended  to  include  real-time  play-back.  The  recorded  situations  are  then 
sequentially  repeated  on  the  tactical  display.  Provisions  for  fast  replay  and  "freeze  event"  are  also 
considered. 
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6.  CONCLUSIONS 


in  order  to  cope  with  the  threat  a highly  integrated  fire  control  system  had  to  be  developed  for  the 
"HAUK"-cl ass  FPB. 

The  corner  stones  in  the  described  system  are: 

Assessment  of  the  tactical  situation 
Assistance  in  decision  making 
Threat  evaluation 
Actions 

The  assessment  of  the  tactical  situation  is  achieved  by: 

The  use  of  multi  sensors  (passive  and  active)  in  the  target  tracking  process. 

Receiving  data  from  friendly  units  by  the  link  system 

Accurate  navigation  by  use  of  inertial  sensors  in  the  stabilized  platform 

Handling,  sorting  and  correlation  of  the  above  mentioned  data  in  the  computer  in  order  to  present 
a clear  and  accurate  picture  for  the  CU. 

Broadcasting  of  synthetic  tactical  information  without  delay  to  friendly  units. 
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The  assistance  in  decision  making  is  achieved  by: 

Using  the  computer  to: 
o Monitor  the  status  of  the  weapons 

o Calculate  predicted  missile  flight-path  and  torpedo  course  and  present  the  solution  on  the 
tactical  display 

o Calculate  attack  position  data  (course  and  speed) 
o Store  geographically  fixed  reference  positions 

The  data  display  showing  the  following  information: 
o Missile  data 

o Torpedo  data 

o Target  data  in  two  pages  on  range/bearing  form 

o Target  data  in  two  pages  on  CCG  form 

o Course  of  attack 

The  evaluation  of  the  threat  and  the  associated  actions  to  be  carried  out  are  done  by: 

The  extensive  use  of  all  the  information  on  the  operator  console  (displays,  numerical  read  outs, 
etc). 

The  latest  information  on  action  taken  by  friendly  units  (link  and  displays) 

Automatic  weapon  assignment  and  control 

By  careful  integration  of  the  above  mentioned  corner  stones  by  the  use  of  modern  technology,  a highly 
versatile  Weapon  Control  System  has  been  developed.  All  obtained  Information  is  available  for  a multitude 
of  users  in  order  to  achieve  surprise,  quick  reaction,  effective  command  and  weapon  control;  all  vital 
ingredients  to  successful  FPB  operations. 

The  new  "HAUlO'-class  will  be  set  into  service  by  the  end  of  this  year,  and  we  believe  that 
worthy  successor  to  the  RNON's  traditions  as  one  of  the  pioneers  in  the  evolution  of  small 
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it  will  be  a 
FPB's. 
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APPENDIX  1 


KNM  "HAUK" ' s Main  Data: 
Displacement,  tons: 
Dimensions,  metres: 
Main  Engines: 

Range,  miles: 
Complement: 


120  standard,  150  full  load 
36,5  x 6,2  x 1 ,6 

2 MTU  diesels;  7000  hp  = 34  knots 
440  at  34  knots 
22 
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EQUIPMENT  SPECIFICATIONS 
Radar: 

LLTV  Camera: 

LRF : 

Stabilized  Platform: 


Solid  State  Navigation  Radar  I-band 

625  lines,  50  half-frame/ sec  4:3  Aspect  Ratio,  Intensified  SIT  tube 
Range  Accuracy  10  m.  Range  30  km 
Type:  3 axis 


Rotation,  Angles: 

Rotation  speed: 
Load: 

Stability: 
Settling  time: 


Roll: 

Pitch: 

Azimuth: 

45°/sec 

100  kg 


+ 45° 

+ 20° 
Unlimited 


Weight: 

Dimensions  of  operators  console: 

Depth : 


Height : 


True  horizontal  0,3  mrad  (lo) 

True  north  9,0  mrad  (lo) 

o Less  than  two  min.  to  settle  within  1 mrad  from  10° 

o Less  than  25  min.  to  settle  within  9 mrad  from  + 10° 
from  true  north 

350  kg 

Length:  2,6  metres 

1,75  metres  including  tactical  display 
1,55  metres 


Weight: 

Power: 


Total  weight  below  deck  approx.:  1200  kg 

Total  weight  operators  console  approx.  1000  kg 

Total  power  consumption  approx.  10  kVA  from  3 x 115  Volt/60  Hz,  Mil.  Std.  461. 
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ENVIRONMENTAL  SPECIFICATIONS 


SYSTEM  AND  MAIN  UNITS 


Severity 

Environment 

Functioning 

Functioning 

Test  procedure/Remarks 

during  test 

after  test 

1. 

Vibration 

a)  After  region 

5-20  Hz : +1 ,0  inn 

IEC  68-2-6  Test  Fc 

20-100  Hz  1 ,6  g 

b)  Main  region 

5-20  Hz: +0,63  urn 

IEC  68-2-6  Test,  Fc,  81 

20-100  Hz:  1,0  g 

2. 

Shock 

2 shocks  in 

each  of  the 
main  direc- 
tions!) 

ER-SG 

3. 

Temperature 

3..1 

Equipment  below 
deck 

a)  Low  temp. 

0°C 

-40°C 

ER-CC  para.  1 

b)  High  temp. 

+55°C 

+70°C 

ER-CC  para.  2 

c)  Temp,  cycling 

0°C  to  55°C 

ER-CC  para.  3 

3.2 

Equipment  above 
deck 

a)  Low  temp. 

-25°C 

-40°C 

ER-CC  para.  1 

b)  High  temp. 

+55°C 

+70°C 

ER-CC  para . 2 

c)  Temp,  cycling 

-25°C  to  +55°C 

ER-CC  para.  3 

4. 

20-58°C 

80-100%  RH 

ER-CC  para.  4 

5. 

1 

3,5%  salt 

ER-CC  para.  5 

solution 

test  on  representative 

35+5° 

details 

6. 

Enclosure 

a)  Below  deck 

Rain  proof 

ER-CC  para  9b 

b)  Above  deck 

Driving  rain 

ER-CC  para.  9c  Test  II 

7. 

Ice  Formation 

Water  of  0+3°C 

ER-CC  para.  8 

running  over  the 

15-20  times  per  hour  for 

eg.  stabilized  at 
-10+2° 

4 hours 

8. 

Wind 

Winds  at  40  m/s 

ER-CC  para.  10 



and  wind  gusts 
of  50  m/s 

1)  Shock  loading  according  to  equipment  weight 

Example:  240  - 700  kg:  T * 3 ms  55  g 27  g,  22  g (Vertical,  Athwartshlp,  Longitud.) 

T * 13  ms  13  g 6 g,  5 g (Vertical,  Athwartshlp,  Longitud.) 
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o ER:  Draft  Proposal  Requirements  Royal  Norwegian  Navy,  Feb.  1969 
o 1EC:  International  Electrotechnical  Commision  Geneva,  Suisse, 
o Most  of  the  above  mentioned  specifications  comply  with  DEF  133  class  N1  and  N2 
o The  only  exception  from  the  environmental  specifications  is  the  tapes  for  the  cassette  recorder. 
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R.C.Makin 

It  seemed  from  the  photograph  of  the  console  that  the  fire  control  indicators  and  controls  were  hardwired.  Is  this 
true? 

Author’s  Reply 

All  the  controls  are  under  software  control.  Some  of  the  keys  have  fixed  function  (text),  for  instance  the  Fire-button. 
Others  have  multiple  functions,  where  the  text  is  given  by  the  text  in  film  displays,  etc. 


Y.Brault 

If  my  understanding  is  correct  you  intend  to  have  in  the  future  both  LLTV  and  Thermal  1R.  Is  it  your  intention  to 
display  the  TV  output  or  the  IR  output  or  do  you  intend  to  provide  a combined  image? 


Author’s  Reply 

We  intend  to  provide  a combined  image. 


JOINT  TACTICAL  INFORMATION  DISTRIBUTION  SYSTEM 
(JTIDS) 


WEAPON  DELIVERY  APPLICATIONS 


CLAUDE  E.  OWEN 
NAVAL  WEAPONS  CENTER 
CHINA  LAKE,  C'A  93555 

WEAPON  GUIDANCE  AND  WEAPON  DELIVERY  APPLICATIONS  OF  JTIDS 


SUMMARY 


This  paper  addresses  the  application  of  JTIDS,  which  is  a secure  communications  system,  and  the  tactical  data  processing 
of  key  data  within  that  system,  to  satisfy  a tactical  systems  requirement  of  weapon  delivery.  The  capabilities  of  the  JTIDS 
relative  navigation  to  provide  correlated  time  and  position  among  all  community  members  is  especially  important  in  this 
application.  In  addition,  one  of  the  primary  tasks  in  the  application  of  JTIDS  to  solving  the  weapon  guidance  problem  is  that 
of  placing  the  target  coordinates  into  the  relative  navigation  grid. 

1.  INTRODUCTION 

The  relative  navigation  capability  of  TriDS  is  an  outgrowth  of  a previously  developed  Navy  hybrid  navigation  system 
called  the  Integrated  Tactical  l.avigation  System  (1TNS).  However,  1TNS  lacked  the  secure  data  link  capability  of  JTIDS. 

The  tactical  hybrid  navigation  sub-system  within  JTIDS  allows  for  the  effective  coordination  of  air,  ground,  and  sea 
based  systems  through  cooperative  use  of  the  navigation  sensor  resources  of  all  members  in  a tactical  community.  An  ntegrated 
communications  capability  is  required  in  this  system  approach  and  is  briefly  discussed.  This  concept  is  based  upon  the  premise 
that  the  global  sphere  of  required  cooperative  vehicle  activity  may  be  divided  into  various  tactically  self-contained  areas  within 
which  navigation,  communication,  and  identification  of  ail  community  elements  is  required  to  a more  fine  grain  resolution  than 
that  required  for  global  operation.  Thus,  within  the  tactical  area  a common  relative  navigation  grid  system  with  tactically 
self-contained  communication  capability  is  required. 

2.  JTIDS  CONCEPT  AND  CAPABILITIES 

JTIDS  provides  tactical  commanders  with  standardized  interoperable  systems  by  which  all  members  of  a tactical 
community  are  interconnected  in  an  RF  data  link  permitting  jam-resistant  crypto-secure  communication,  precision  relative 
navigation,  TAC'AN,  and  inherent  identitication  capability.  The  capability  of  JTIDS  is  shared  among  participants  on  the  basis  of 
time  division,  using  a technique  known  as  time-division  multiple-access  (TDMA).  Each  participant  in  the  JTIDS  network  is 
assigned  a sufficient  number  of  time  slots  to  accommodate  the  number  of  messages  likely  to  be  required  by  his  mission.  During 
his  assigned  transmit  time  slots,  each  user  broadcasts  data  into  a commonly  accessible  communications  data  stream  represented 
by  a TDMA  ring  (see  Fig.  1).  All  other  elements  can  extract  information  of  the  type  they  require  by  continuously  monitoring 
and  sampling  the  data  base.  The  relative  navigation  capability  is  provided  by  making  use  of  onboard  sensors.  In  operation,  the 
dead  reckoning  equipment  senses  vehicle  motion  and  the  computer  calculates  position  by  integration.  A position  report  from  a 
remote  unit  is  received  via  the  JTIDS  link  and  the  time  of  arrival  (TOA)  of  this  message  indicates  the  range  to  the  remote  unit. 
Using  this  information,  a correction  to  the  estimate  of  own  position  is  calculated  and  applied.  In  turn,  a position  report  is 
transmitted  via  JTIDS  for  use  by  other  members  (see  Fig.  2). 

The  coordinate  frame  used  for  position  reporting  in  the  relative  grid  is  a tangent  plane  grid,  a rectangular  grid  tangent  to 
the  earth  at  the  origin,  which  is  nominally  stationary.  The  origin  and  the  grid  are  located  arbitrarily,  but  all  members  accept 
the  location  identified  by  one  member  of  the  community  designated  as  controller.  From  the  transmitted  data,  the  apparent 
relative  position  of  each  community  member  is  determined.  If  each  member’s  self-contained  grid  is  co-aligned,  this  apparent 
relative  position  should  be  the  same  as  the  relative  positions  measured  by  the  radio  ranging.  The  difference  between  the 
measured  and  apparent  relative  position  provides  the  error  signals  which  enable  each  member  to  align  his  self-contained  grid  to 
community  grid.  Thus,  members  each  have  accurate  navigation  in  the  tactical  grid  in  spite  of  geographic  navigation  eirors  (see 
Fig.  3). 

2.1  APPLICATION  OF  JTIDS  NAVIGATION  TO  WEAPON  DELIVERY 

JTIDS  relative  navigation  affords  members  of  the  same  mission  or  community  the  ability  to  acquire  targets,  effect 
rendezvous,  exchange  position  data  and  deliver  weapons  effectively  and  accurately  within  a designated  relative  coordinate  system. 
Accurate  navigation  within  the  community  is  accomplished  because  azimuthal,  position,  and  time  correlation  exists  among  the 
community  members.  Any  member  possesses  the  navigation  accuracy  by  effectively  touching  any  other  members  with  an 
imaginary  stick  or,  perhaps  more  significantly,  to  touch  any  arbitrary  point  in  the  tactical  region  via  other  member  or  members 
as  if  a sequence  of  rods  were  connected.  This  is  realized  through  the  use  of  a relative  grid  which  is  common  among  the  users 
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and  each  and  every  member  positions  himself  in  that  grid  as  well  as  aligning  his  axes  to  the  grid  and  to  a common  azimuth. 
Fig.  4 graphically  depicts  active  position  filtering. 

No  member  represents  an  independent  entity,  but  rather  is  an  integral  part  of  a network  of  users  linked  together  hy  a 
precise  RF  ranging  system.  Relative  position  is  known  so  well  that  this  network  of  members  can  be  thought  of  as  one  hybrid 
navigation/weapon  delivery  system  with  distributed  sensors.  The  relative  grid  provides  a single  measurement  base  in  which  the 
precise  exchange  of  each  member’s  sensor  data  occurs.  For  combat  consideration,  this  means  that  target  positions  and  other 
points  of  interest  can  be  exchanged  among  members  of  the  community  with  great  accuracy.  This  same  relative  grid  allows  for 
the  distribution  of  precise  geographic  position  data  (e.g.,  GPS  data  if  available)  for  direct  use  by  the  mutual  augmentation  of 
the  distribution  geographic  (velocity)  navigation  sensors,  just  as  if  they  were  located  on  the  same  vehicle  (e.g,  a Doppler  on  one 
vehicle  being  utilized  with  an  inertial  system  ir  a second  vehicle  to  provide  a hybrid  Doppler  inertial  capability).  Members 
carrying  different  sensors  and  sensor  types,  with  different  error  signatures,  augment  each  other  to  provide  a hybrid  system 
which  is  more  accurate  than  any  single  system  element  alone. 

2.2  JT1DS  NAVIGATION  GUIDANCE 

Another  weapons  delivery  application  of  JTIDS  is  the  combining  of  the  possible  improvements  in  radar  targeting  with 
the  guidance  of  long-range  missiles.  This  application  of  JTIDS  can  provide  an  Over-the-Horizon  (OTH)  targeting  capability  using 
JTIDS  information  correlated  with  other  sensor  information. 

This  JTIDS  weapon  delivery  system  would  consist  of  a long-range  weapon  and  aircraft  to  provide  target  position  updates 
and  weapon  guidance  information.  The  aircraft  radars  could  be  used  for  locating  and  tracking  surface  ship  targets  in  near 
real-time.  Onboard  computers  would  process  radar  bearing  and  range  data  to  determine  the  target  coordinates  in  the  relative 
navigation  grid. 

Missile  location  would  be  performed  by  using  the  JTIDS  round-trip-timing  (RTT)  capability.  This  capability  permits 
multiple  units  to  measure  range  to  the  missile.  The  JTIDS  relative  navigation  capability  allows  each  of  these  units  to  position 
tag  the  range.  These  position  tagged  range  measurements  are  then  sent  to  a central  unit  via  the  JTIDS  data  link  so  that  the 
missile  position  can  be  calculated.  This  capability  allows  near  real-time  missile  position  data.  Based  upon  this  missile  position 
and  the  target  pos'tion  a midcourse  guidance  update  message  can  be  generated. 

Periodically  these  JTIDS  midcourse  guidance  messages  would  be  transmitted  and  could  -ontain  missile  and  target 
coordinate  data  and  other  data  as  may  be  deemed  necessary.  The  missile  guidance  unit  would  process  the  guidance  message  and 
combine  it  with  missile  autopilot  data  to  determine  midcourse  guidance  corrections.  In  this  way,  midcourse  errors  caused  by  the 
buildup  of  missile  autopilot  errors  and  wind  and  target  motion,  which  build  up  over  the  period  of  flight  time,  will  be  greatly 
reduced.  Consequently,  area  search  requirements  for  target  acquisition  will  be  minimized  and  may  even  be  unnecessary.  This 
system  mechanization  will  make  it  possible  to  delay  terminal  seeker  activation  until  within  a few  miles  of  the  target  and.  in 
addition,  it  will  provide  the  target  selectivity  and  greater  weapon  survivability. 

2.3  JTIDS  AIDED  BOMB  DELIVERY 

The  JTIDS  system  also  provides  a capability  for  a high-accuracy  all-weather  navigation  bombing  capability  for  delivery  of 
the  standard  bomb.  A fundamental  requirement  for  this  weapon  delivery  capability  is  the  accurate  determination  of  iclative 
position  between  the  weapon  delivery  vehicle  and  the  target. 

The  JTIDS  system  provides  the  accurate  position  data  required  to  achieve  the  high  accuracy  navigation  bombing 
capability. 

A weapon  delivery  system,  using  JTIDS  for  position  determination  of  the  weapon  delivery  vehicle  and  the  target,  and 
integrated  with  the  existing  navigation  bombing  capability  of  an  attack  aircraft,  provides  a greatly  enhanced  capability  for  bomb 
delivery. 

Target  position  in  the  JTIDS  grid  can  be  determined  by  a number  of  methods,  such  as  Flyover  Mark  or  target  data,  can 
be  provided  by  other  JTIDS-equipped  platforms. 

Once  the  target  is  located  in  the  JTIDS  coordinate  system,  navigation  bombing  is  possible.  There  are  no  limitations  to 
the  type  of  delivery  or  tactics  to  be  used. 

A by-product  of  the  JTIDS  system  is  improved  velocity  accuracy  of  the  weapon  delivery  vehicle  in  a coordinate  frame- 
related  to  the  target  information.  Thus  the  miss  distance  of  a weapon  in  the  navigation  bomb  mode  is  decreased  as  a result  of 
improved  position  and  velocity  information.  In  the  conventional  method  of  weapon  delivery  Heads  Up  Displays  (HUD)  and 
ranging  radar,  there  is  also  an  improvement  in  weapon  delivery  accuracy,  since  the  improved  velocity  accuracy  reduces  the  miss 
distance  of  the  weapon. 


2.4  ANALYSES  AND  STUDIES 
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The  Naval  Weapons  Center  (NWC)  in  conjunction  with  various  contractors  has  performed  a number  of  analyses  and 
simulations  in  the  area  of  relative  navigation  and  its  applicability  to  solving  both  the  targeting  and  weapon  delivery  problem. 
These  studies  date  back  over  the  past  five  years  and  were  originally  started  considering  the  1TNS  hardware.  However,  they  were 
later  directed  toward  the  use  of  the  JTIDS  hardware  to  implement  a demonstration  system  employing  this  capability.  The 
present  NWC  program  performing  work  in  this  area  is  called  JTIDS/Joint  Air  Weapon  System  or  JTIDS/JAWS. 

The  Kearfott  Division  of  the  Singer  Company  performed  much  of  the  early  work  for  NWC  and  designed  both  a system, 
a Walleye  digital  autopilot  and  performed  a successful  simulation  program  of  this  system  using  the  ITNS  hardware.  They  later 
upgraded  the  demonstration  system  design  to  make  it  applicable  to  JTIDS  and  its  waveform  structure. 

IBM  Federal  Systems  Division  also  performed  numerous  analyses  and  simulations  relative  to  a somewhat  different  but  yet 
related  system  mechanization. 

In  addition  to  contracted  work,  IBM  performed  in-house  studies  in  support  of  the  JTIDS/JAWS  effort  and  has  developed 
hardware  to  deliver  to  the  Navy  for  use  in  laboratory  and  captive  demonstration  of  the  weapon  data  link.  Fig  5 is  a mockup 
of  a weapon  data  link  module  proposed  by  IBM.  This  specific  form  factor  docs  not  represent  the  ultimate  packing  density,  but 
it  is  merely  a first  cut  at  re-packaging  their  present  “Brass  Board  Unit.” 

A specific  guidance  mechanization  was  developed  and  documented  during  this  effort.  This  was  later  expanded  by  a 
contract  which  NWC  had  with  Ford  Aerospace  and  Communications  Corp.  The  Ford  effort  referred  to  as  MAGNA  II 
(Microcomputer  Application  to  Guidance  and  Navigation  Aids)  was  intended  to  exploit  the  military  application  of  Ford’s 
low-cost  microcomputer.  Using  the  Singer  algorithms,  Ford  mechanized  a digital  autopilot  for  the  Walleye  missile.  This  was 
subsequently  tested  in  a flight  simulation  at  NWC. 

Recently  much  of  the  study  effort  that  has  gone  into  the  weapon  delivery  application  of  JTIDS  has  been  directed 
towards  the  Tomahawk  Anti-Ship  Missile  (TASM)  application.  Guidance  schemes  and  equipment  configurations  have  been 
developed  and  are  being  studied  using  the  techniques  described  in  this  paper  to  provide  this  type  of  missile  with  an 
Over-the-Horizon  targeting  capability. 


3.  CONCLUSION 

This  paper  has  been  intentionally  kept  very  general  in  order  to  avoid  sensitive  or  classified  areas.  However,  the  key  point 
to  be  made  is  that  the  relative  navigation  capability  of  JTIDS  coupled  with  the  tactical  data  processing  of  community  sensor 
data  can  be  used  to  improve  the  solution  to  the  overall  fire  control  and  ordnance  delivery  problem. 

In  addition,  a grid  locked  community  of  users  appears  to  be  another  key  element  in  solving  many  of  the  other  problems 
of  tactical  command  and  control. 

A demonstration  system  concept  is  shown  by  Fig.  6 and  the  overall  system  mechanization  to  accomplish  this 
demonstration  is  described  by  Fig.  7.  Presently  this  hardware  is  undergoing  system  test  at  the  Naval  Air  Development  Center 
(NADC)  in  Warminster,  PA. 
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FIGURE  1.  TDMA  Structure. 


INTERROGATING  SUBSCRIBER 

toar  - e + 'p 

e + TOAj  - td  + tp 


TOA  - T0AI  + *d 


where : 

TOAr  = TOA  of  interrogation  at  Replying  Subscriber 

TOAj  = TOA  of  reply  at  Interrogating  Subscriber 

e = initial  clock  offset  between  Replying  and  Interrogating 
clock  (i.e.,  error) 
t = Propagation  delay 

t^  = One  of  two  possible  fixed  time  delays  at  replying  sub- 
scriber measured  from  start  of  time  slot. 

Note:  Assumes  that  t,  is  short  enough  so  that  t is  constant  for 
both  interrogation  and  reply  even  if  both^subscribers  are 
in  motion. 


FIGURE  2.  General  RTT  Algorithm. 
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FIGURE  3.  Position  Location  Using  Time-of-Arrival  Data. 
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FIGURE  4.  Active  Mode  Grid  Position  Estimation. 


FIGURE  5.  JTIDS/Fxpendable  Terminal. 
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RESUME 


La  mesure  de  distance  DME  permet  d'effectuer,  avec  le  VOR,  la  navigation  a moyenne  distance.  Son 
utilisation  est  egalement  prevue  pour  l'aide  a 1 'atterrissage  avec  l'lLS  et  le  MLS. 

Apres  un  rappel  des  performances  principales  fournies  par  le  systeme  actuel , seront  evoquees  les 
ameliorations  apportees  aux  equipements  de  bord  par  l'emploi  des  nouvelles  technologies. 

Actuel lenent,  le  systeme  est  tout  a fait  satisfaisant,  mais  il  risque  de  presenter,  dans  l'avenir, 
quelques  limitations  operationnel les  qui  peuvent  facilement  etre  eiiminees.  Par  exemple,  la  saturation  des 
balises  est  evitable  en  utilisant  la  technique  "DME  a sens  quasi  unique",  de  m6me  la  precision  pour  l'atter- 
rissage  peut  etre  accrue  par  1 ‘utilisation  d'impulsions  simples  codees  en  phase,  les  200  canaux  supplemen- 
tal res  etant  fournis  en  m&me  temps. 

Une  navigation  precise  basee  uniquement  sur  des  mesures  de  distance  est  envisageable,  les  donnees 
geographiques  concernant  chaque  balise  pouvant  etre  transmises  sur  le  canal  DME. 

1.  INTRODUCTION 


Le  DME  constitue  la  partie  mesure  de  distance  du  systeme  de  navigation  4 coordonnees  polaires 
standardise  par  l'OACI. 

L'idee  d'un  principe  de  navigation  utilisant  les  coordonnees  p ec  e a ete  adoptee  depuis  plus  de 
30  ans  et  des  1949,  la  fonction  azimut  etait  fournie  dans  la  bande  V.H.F.  par  le  VOR  alors  que  la  fonction 
distance  etait  prevue  dans  une  autre  bande  de  frequence  rgservee  4 1 'aeronautique  de  960  MHz  4 1215  MHz. 

Vers  cette  epoque,  deux  systemes  de  mesure  de  distance  fonctionnant  en  impulsions  etaient  en 
presence  : l'un  a large  bande  (20  MHz  par  canal)  qui  eut  peu  de  developpement  par  la  suite,  utilisait  une 
dizaine  de  codages  diff&rents  de  l'espacement  des  paires  d'impulsions  pour  obtenir  un  nombre  suffisant  de 
canaux,  l'autre  4 bande  etroite  (6  MHz  par  canal  dans  les  debuts),  avec  pilotage  des  frequences  par  quartz, 
se  developpa  et  se  perfectionna  continuellement  pour  donner  naissance  au  systeme  militaire  TACAN  qui  resta 
protege  par  le  secret  jusqu'en  1955. 

C'est  finalement  en  1959  que  l'OACI  adopta  definitivement  le  systeme  V0R-DME  utilisant  dans  son 
integralite  la  partie  distance  du  systeme  TACAN. 

Depuis  cette  date,  1 'infrastructure  au  sol  en  balises  fournissant  la  distance  DME  n'a  pas  cesse 
de  s'etendre. 

Actuel lement,  aux  Etats-Unis,  environ  1000  stations  VORTAC  et  DME  sont  operationnel les. 

Dans  la  zfine  europeenne,  on  denombre  pres  de  270  stations  OACI  VOR-DME  ou  VORTAC  operationnel les 
auxquelles  il  convient  d'ajouter  230  stations  TACAN  ou  DME  reservees  4 des  usages  nationaux.  On  prevoit, 
dans  les  annees  4 venir,  un  total  de  350  stations  OACI  et  280  stations  nationales. 

En  France,  31  stations  OACI  sur  44  prevues  sont  actuellement  operationnel les  et  il  y a approximati- 
vement  le  meme  nombre  de  balises  TACAN  sol  utilisees  par  1 'aviation  militaire.  (Voir  Fig.  1 et  2). 

En  ce  qui  concerne  les  appareils  de  bord,  le  nombre  des  utilisateurs  du  DME  est  evalue  4 environ 
70.000.  Ce  nombre  est  en  croissance  rapide  avec  le  developpement  de  1 'aviation  d'affaires  et  de  l'aviation 
generale,  ou  des  besoins  nouveaux  sont  crees  par  1 'obligation  de  s'equiper  pour  effectuer  les  procedures 
dans  certaines  zones  terminales  (TWA).  En  France  par  exemple,  le  DME  est  maintenant  obligatoire  pour  acce- 
der  en  IFR  4 la  TMA  de  PARIS  et  il  est  recommande  dans  les  TMA  de  LILLE  et  STRASBOURG. 

L'utilisation  du  DME  est  egalement  favorisee  par  le  large  choix  d'interrogateurs  proposes  mainte- 
nant sur  le  marche. 

L'extension  du  nombre  des  balises  DME  et  surtout  des  balises  VOR  cree  un  besoin  de  canaux  nouveaux, 
car  il  existe  un  appariement  rigide  et  bi-univoque  entre  les  canaux  VOR/ILS  et  les  canaux  DHE/TACAN. 

Pour  chaque  implantation  de  VOR,  une  frequence  DME  est  mise  en  reserve  et  1 ' attribution  de  nouvelles 
frequences  n'est  pas  sans  poser  de  probiemes  dans  certaines  regions. 

Il  exist.ait,  4 l'origine,  100  canaux  VOR/DME,  chacun  d'eux  ayant  une  frequence  differente.  L'OACI 
prevoyant  les  besoins  futurs  a double  ce  nombre  en  1962,  pour  le  DME  en  introduisant  un  nouveau  code  Y de 
l'espacement  des  impulsions  de  chaque  paire  et  en  utilisant  les  frequences  dej4  existantes,  et  pour  le  VOR 
en  creant  de  nouvelles  frequences  intercaiees  entre  les  anciennes  portant  ainsi  l'espacement  entre  canaux 
VOR  adjacents  4 50  kHz. 


Les  canaux  Y sont  en  fait  restes  jusqu‘3  present  peu  utilises,  surtout  3 cause  des  difficult^  de 
mise  en  exploitation  des  canaux  VOR  associes  espac6s  de  50  kHz.  En  France,  une  seule  station  OACI  en  canal 
Y est  operationnelle  3 1‘Aeroport  Charles  de  Gaulle. 

2.  PERFORMANCES  PRINCIPALES  DU  SYSTEME 

Les  performances  que  l'on  peut  obtenir  du  DME  sont  liees  au  format  du  signal  utilise,  mais  elles 
dependent  egalement  de  la  qualite  des  equipements  sol  et  bord  que  la  technologie  moderne  a permis  d'amelio- 
rer  grandement. 

2.1.  Nombre  de  canaux 

I 1 s sont  au  nombre  de  100  en  mode  X et  100  en  mode  Y.  Dans  chacun  da  ces  modes  sont  prevus  : 

- 60  canaux  couples  aux  VOR  “en  route"  ; 

- 20  canaux  couples  aux  TV0R  de  zones  terminales  ; 

- 20  canaux  couples  aux  ILS. 

Ce  nombre  de  canaux  sera  suffisant  pour  la  duree  de  vie  du  systeme  3 condition  que  les  developpe- 
ments  du  DME  de  precision  pour  l'atterrissage  ne  viennent  pas  en  reduire  la  disponibilite. 


La  portee  maximum  obtenue  est  evidemment  variable  suivant  la  classe  de  1 ‘interrogateur  utilise. 

Jusqu'3  une  distance  de  200milles  nautiques,  la  portee  est  pratiquement  egale  3 la  portee  optique 
correspondant  3 V altitude  de  vol,  ceci  avec  une  balise  repondant  aux  normes  OACI  et  un  interrogateur  de 
performances  minimales  pour  etre  homologue  en  categorie  A (puissance  d'emission  250  watts  et  sensibilite 
du  recepteur  : -81  dBm) . 

Pour  une  portee  supdrieure  a 200milles  nautiques,  un  interrogateur  plus  performant  est  necessaire. 

2.3.  Precision  en  distance 

La  precision  sur  la  mesure  de  distance  obtenue  couramment  avec  les  equipements  de  bord  modernes  est 
meilleure  que  + 0,2  MN  (1  a).  Cette  precision  reste  pratiquement  constante  quelle  que  soit  la  distance 
mesuree  dans  la  limite  de  portee.  El le  inclut  3 la  fois  les  erreurs  de  la  balise  et  de  V interrogateur, 
chacune  comptant  3 peu  pres  pour  la  moitie.  Rappelons,  pour  memoire,  que  les  performances  minimales  imposent 
une  precision  de  + 0,5  MN  ou  2 % de  la  distance. 

Depuis  1 'etablissement  de  cette  norme,  de  grandes  ameliorations  ont  ete  apportees,  surtout  par  le 
traitement  numerique  de  la  mesure  de  distance  et  par  1 ' u ti  1 i sati on  de  circui.s  speciaux. 

La  reduction  des  erreurs  a porte  3 la  fois  sur  les  erreurs  de  biais  et  les  erreurs  de  bruit. 

Les  erreurs  de  biais  ont  ete  reduites  en  effectuant  les  mesures  de  temps  au  moyen  d'une  horloge 
pilotee  par  quartz,  3 partir  d'un  marquage  precis  du  front  avant  de  la  mi-amplitude  des  impulsions  et  en 
ccmpensant  automatiquement  les  retards  apportes  par  les  circuits  3 bandes  passantes  limitees  au  moyen  d'une 
metnode  analogue  3 une  double  pesee  appelde  "impulsions  pilotes". 

Les  erreurs  de  bruit  ont  ete  diminuees  dans  1 'interrogateur  : 

- par  une  seiectivite  temporelle,  en  effectuant  la  poursuite  avec  une  porte  etroite  (moins  de  10, us)  centree 

sur  les  reponses  de  la  balise  au  moyen  d'un  asservissement  ; ' 

- par  filtrage,  en  integrant  la  mesure  de  distance  sur  plusieurs  cycles  d' interrogations-reponses  et  en 
corrigeant  le  retard  apporte  par  l'integration. 

Les  erreurs  de  multitrajets  qui  peuvent  etre  considArees  3 la  fois  canme  des  erreurs  de  biais  et 

des  erreurs  de  bruit  ont  ete  reduites  en  effectuant  les  mesures  de  temps  3 partir  des  fronts  avant  des 

premieres  impulsions  de  chaque  paire  avant  l'arrivee  de  1'echo  eventuel . 

En  utilisant  les  techniques  enoncees  precedemment,  la  meilleure  precision  que  l'on  puisse  obtenir 
sans  complication  excessive  et  sans  grever  exagerement  le  prix  des  equipements  est  environ  + 80  metres. 

Une  etude  et  une  mesure  experimentale  des  erreurs  DME  figurent  dans  1' article  de  MM.  R.W.  LATHAM 

et  R.S.  TOWNES  cite  en  reference  1. 

2.4.  Capacite  des  balises 


Les  balises  ont  une  cadence  d'emission  qui  leur  permet  de  repondre  simultanement  3 100  avions.  Cette 
capacite  est  en  general  suffisante,  cependant  dans  certaines  zones  3 forte  densite  de  trafic,  on  a parfois 
observe  une  saturation  du  DME. 

La  croissance  du  trafic  et  l'augmentation  du  nombre  des  interrogateurs  peuvent,  dans  1'avenir, 
aggraver  cette  situation  et  nous  verrons  dans  la  suite  comment  eviter  cette  eventuelle  saturation  des 
balises. 
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2.5.  Utilisation  de  I'information  de  distance 

La  distance  calcul#e  par  1 ‘ interrogates  est  transmise  au  calculateur  de  navigation  et  aux  indica- 
teurs  de  planche  de  bord  sous  forme  num#rique. 

En  plus  de  I'information  de  distance,  certains  indicateurs  fournissent  egalement  au  pilote  les 
informations  de  vitesse  radiale  et  de  temps  a la  station  qui  sont  tr#s  appr#ci#es  dans  les  avions  non 
#quip#s  de  calculateur  de  navigation. 

Les  systemes  d'affichage  numerique  utilises  dans  les  indicateurs  ont  progress#  ces  dernieres  annees 
et  si  les  afficheurs  mecaniques  a tambours  ont  encore  de  chauds  partisans,  les  chiffres  lumineux  sont  mainte- 
nant  bien  acceptes  des  uti lisateurs , car  leur  lisibilit#  est  bonne  malgr#  les  fortes  variations  de  luminosit# 
auxquelles  sont  soumises  les  cabines  de  pilotage.  Un  nouveau  type  d'afficheur  3 cristaux  liquides  special 
pour  applications  aeronautiques  apparaft  sur  )e  march#,  i)  r#unit  3 la  fois  les  avantages  d'une  bonne  1 isi - 
bilit#  et  de  faible  consommation.  Ce  sera  probablement  la  solution  pour  l'avenir. 

Les  interrogateurs  modernes  fournissent  une  information  de  distance  de  grande  stabi lit#.  Le  pilote 
ne  se  rend  pas  compte  des  pertes  passag#res  du  signal  dues  surtout  aux  evolutions  de  1 ‘avion,  car  il  voit 
d#filer  r#gul ierement  la  distance  grSce  a une  m#moire  dynamique  qui  peut  durer  jusqu'3  12  secondes.  M#me 
si  l'absence  de  signal  se  prolonge  au  del#  du  temps  de  m#moire  et  que  I'information  de  distance  disparatt, 

le  temps  de  r#acquisition  est  tr#s  bref  (de  1 a 2 secondes)  lorsque  les  conditions  redeviennent  normales. 

II  est  d'ailleurs  le  meme  apr#s  un  changement  de  canal  pour  s#lectionner  une  autre  balise. 

3.  EVOLUTION  DES  EQUIPEMENTS  DE  BORD 

Les  #quipements  DME  utilises  pour  la  navigation  poss#dent  d#j3  depuis  plusieurs  ann#es  un  syntheti- 
seur  de  frequence  et  un  #metteur  a large  bande.  revolution  actuelle  concerne  surtout  1 'utilisation  d'un 
#metteur  completement  transistorise  et  de  mi croprocesseurs  pour  le  traitement  video  de  la  distance. 

Les  d#veloppements  militaires  du  TACAN  ont  fait  apparaftre  sur  le  march#  des  transistors  UHF  pour  la 
realisation  d'amplificateurs  de  puissance  enti#rement  "#tat  solide"  permettant  d'eliminer  completement  les 
tubes  des  #quipements.  Les  avantages  resultants  sont  avant  tout  une  diminution  importante  de  la  puissance 
dissip#e  et  une  amelioration  de  la  fiabilit#. 

Dans  le  domaine  civil,  bien  que  le  prix  de  tels  ampl i fi cateurs  soit  encore  plus  #lev#  que  1 'equiva- 
lent a tubes,  les  premiers  #quipements  completement  transistorises  fournissant  une  puissance  sup#rieure  3 
500  watts  apparaissent  aux  Etats-Unis. 

Le  calcul  de  la  distance  effectu#  jusqu'3  present  au  moyen  de  logique  cabl#e  peut  maintenant  etre 
realise  en  logique  programmee.  Cependant,  ce  traitement  ne  doit  pas  etre  applique  seulement  3 la  distance, 
sinon  le  microprocesseur  reste  sous-employ#  et  le  bilan  comparatif  est  d#favorable  au  point  de  vue  nombre 
de  microcircuits,  consommation  electrique  et  coGt. 

En  fait,  le  microprocesseur  peut  traiter  beaucoup  d'autres  fonctions  et  il  devient  alors  tout  a 
fait  rentable,  car  il  permet  d'ameiiorer  encore  les  performances  de  1 'interrogateur  et  de  fournir  de 
nouvelles  fonctions. 

Il  peut  etre  charge  d'effectuer  les  traitements  supplemental' res  suivants  : 

- transcodage  entre  la  boite  de  commande  et  le  synthetiseur  ; 

- calcul  precis  de  la  vitesse  radiale  et  lissage  de  cette  vitesse  ; 

- calcul  de  la  distance  sol  vraie  en  effectuant  une  correction  de  distance  oblique  au  moyen  des  informations 
d' altitude  de  1' avion  par  rapport  3 la  balise  ; 

- calcul  simultan#  de  la  distance  3 plusieurs  balises  ; 

- calcul  de  navigation  n'utilisant  que  la  distance  DME  3 plusieurs  balises,  surtout  pour  equipements 
d' aviation  general e ou  d'affaires. 

Un  modele  de  calcul  de  la  position  3 partir  de  plusieurs  balises  DME  est  donn#  dans  1 'article  de 
R.W.  LATHAM  cite  en  reference  2. 

On  doit  retenir  egalement  une  interessante  suggestion  faite  par  ce  meme  auteur  pour  une  utilisation 
op#rationnel le  de  la  nagigation  rho-rho  au  lieu  de  revenir  au  regime  recherche  de  la  distance  3 chaque 
changement  de  station,  le  calculateur  (3  microprocesseur)  de  l'equipement  de  bord  determine  3 priori  la 
position  de  la  porte  de  distance  relative  3 la  nouvelle  station,  ce  qui  permet  d'#viter,  au  moment  de  la 
commutation,  le  taux  #lev#  d' interrogations  utilise  habituellement  pour  une  premiere  acquisition  de  la 
distance. 

4.  LIMITATIONS  DU  SVSTEME  DME 

Le  DME  r#pond  parfaitement  aux  besoins  actuels  pour  la  navigation.  Les  seules  limitations  possibles 
dans  le  futur  concernent  la  saturation  #ventuelle  des  balises  et  la  precision  insuffisante  pour  une  appli- 
cation 3 1 'atterrissage. 
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4.1.  Saturation  des  balises 


D'une  maniere  normale,  urie  balise  ne  repond  jamais  a toutes  les  interrogations  des  appareils  de 
bord.  El le  ne  peut  pas  en  effet  emettre  une  reponse  destin#e  3 un  avion  donn#  et  simultan#ment  recevoir 
une  interrogation  provenant  d‘un  autre  avion.  Les  interrogateurs  sont  d'ailleurs  pr#vus  pour  fonctionner 
avec  un  taux  de  reponse  nominal  de  70%. 

Lorsqu'une  balise  DME  a en  charge  un  nombre  trop  important  d'avions  equipes  de  DME,  elle  r#pond  a 
chaque  avion  avec  un  taux  inferieur  a la  normale.  Cette  anomalie  se  traduit  a bord  par  des  interruptions 
d'affichage  de  la  distance  et,  dans  les  cas  extremes,  par  une  impossibilit#  d'acquerir  la  distance. 

Plusieurs  remedes  sont  possibles  pour  eviter  cette  saturation  : 

- augmenter  le  nombre  des  paires  d'impulsions  #mises  par  la  balise.  Malheureusement,  1 1 augmentati on  corres- 
pondante  du  taux  de  charge  de  l'emetteur  et  des  temps  morts  de  la  balise  impose  une  limitation  ; 

- diminuer  les  cadences  d' interrogation  des  equipements  de  bord.  Les  cadences  sont  limit#es  3 150  paires 
par  seconde  en  mode  recherche  et  30  paires  par  seconde  en  poursuite.  En  fait,  les  equipements  modernes 
permettent  des  vitesses  de  poursuite  jusqu'3  2000  ou  3000  noeuds  avec  des  cadences  de  10  3 20  paires  par 
seconde.  II  faut  remarquer,  cependant,  que  la  precision  sur  la  mesure  de  la  distance  diminue  en  meme 
temps  que  la  cadence  d1 interrogation  ; 

- il  est  possible  de  diminuer  beaucoup  plus  les  cadences  d'interrogation  en  associant  au  DME  le  systeme 
3 inertie  qui  effectuerait  un  lissage  des  informations  DME  fournies  3 des  intervalles  de  temps  qui 
pourraient  etre  asset  longs.  Ce  principe  n'est  applicable  qu'aux  seuls  avions  equipes  de  l’inertie.  Une 
telle  etude,  avec  application  experimental,  a ete  faite,  et  ses  resultats  figurent  dans  Tarticle  de 
W.E.  TANNER  cite  en  reference  3 ; 

- une  solution  plus  radicale  pour  accrottre  la  capacite  des  balises  est  Tutilisation  de  la  technique  du 
DME  3 sens  quasi-unique.  La  balise  emet  en  plus  des  signaux  DME  habituels  un  signal  d'horloge  basse 
frequence  tres  stable  constitue  de  paires  ou  de  triplets  d'impulsions  codees  specialement.  L'interroga- 
teur  semblabUe  aux  equipements  actuels  comporte  en  plus  une  horloge  locale  synchronisable  sur  l'horloge 

de  la  balise  au  moyen  de  cycles  "interrogation-reponse"  conventionnels.  La  cadence  d'interrogation  normale 
pendant  la  phase  de  synchronisation  de  l'horloge  est  ensuite  tres  lente  en  regime  etabli.  Elle  peut  ainsi 
etre  diminuee  dans  un  rapport  10  sans  perte  de  precision  en  distance  appreciable.  II  suffit,  en  effet, 
d'utiliser  une  horloge  3 quartz  ayant  une  stabilite  de  10-8  pour  avoir  une  duree  atteignant  2 secondes 
entre  chaque  synchronisation.  L'erreur  suppiementai re  maximum  apportee  sur  les  mesures  de  distance  3 sens 
unique  est  alors  de  + 6 metres  (20  nanosecondes . . ) . 

La  distance  3 mesurer  en  mode  trajet  unique  est  proportionnel le  a la  difference  de  phase  entre  l'horloge 
de  bord  synchronisee  et  l'horloge  regue  de  la  balise.  Elle  est  calculee  au  moyen  de  la  mesure  du  temps 
ecoule  entre  1'emission  de  la  balise  d'un  top  d'horloge  et  sa  reception  3 bord,  ce  qui  correspond  au  temps 
de  transit  du  trajet  unique  balise-avion. 

Le  systeme  peut  s'adapter  au  DME  actuel  et  il  est  entierement  compatible. 

Cette  mesure  de  distance  3 sens  quasi-unique  est  tres  interessante  egalement  pour  le  systeme  TACAN.  Outre 
1' accroissement  de  la  capacite  des  balises,  elle  permet  d'augmenter  la  discretion  radio  des  avions  naviguant 
au  moyen  du  TACAN  (voir  article  de  M.  B0HM  cite  en  reference  5). 

Le  signal  emis  par  une  balise  TACAN  comprend  des  trains  d'impulsions  fournissant  les  references  principales 
et  auxiliaires  de  rel#vement  (frequence  de  recurrence  135  Hz).  Ces  signaux  de  reference  peuvent  etre  gene- 
res  3 partir  d'une  horloge  3 tres  haute  stabilite  et  constituer  le  signal  d'horloge  sol  sur  lequel  se 
synchronise  l'horloge  de  1'equipement  de  bord. 

Pour  effectuer  la  synchronisation,  il  faut  connaftre  le  temps  de  propagation  du  signal  de  reference  pro- 
venant de  la  balise,  done  la  distance  de  1 'avion  3 la  balise.  On  peut  synchroniser  l'horloge,  soit  en 
vol  au  moyen  de  mesures  de  distance  par  interrogations-reponses,  soit  au  sol  en  positionnant  l'avion  a une 
distance  connue  de  la  balise.  La  cadence  de  "rafraichissement"  de  la  synchronisation  depend  de  la  stabi- 
lite de  l'horloge  embarquee.  Il  doit  etre  possible  avec  une  horloge  tr#s  stable  et  pour  des  missions  de 
courte  duree  de  n' operer  qu 'en  mode  "trajet  unique"  et  d'observer  un  silence  radio  complet.  La  synchroni- 
sation est  alors  effectuee  une  seule  fois  avant  le  depart  en  mission. 

4.2.  Precision  pour  1 ' atterri ssage 

Il  est  prevu  un  DME  de  precision  fonctionnant  en  bande  L (962-1213  MHz)  associ#  au  systeme  d'atter- 
rissage  MLS  adopt#  par  l'OACI.  La  precision  en  distance  necessaire  pour  ce  DME  doit  #tre  meilleure  que 
100  pieds  (2  a).  Pour  1'obtenir,  il  est  necessaire  de  reduire  considerablement  le  temps  de  montee  du  front 
avant  de  l'impulsion  gaussienne  du  DME  actuel  (2, 5, us).  La  consequence  immediate  est  un  elargissement  du 
spectre  du  signal  et  une  difficult#  pour  trouver  un  nombre  suffisant  de  nouveaux  canaux  qui  ne  perturbent 
pas  les  canaux  d#j3  occupes  dans  cette  bande  de  fr#quence  par  le  DME/TACAN. 

5.  EVOLUTION  FUTURE  POUR  L' ATTERRISSAGE 


Puisque  1' amel ioration  de  la  pr#cision  entraine  in#vi tablement  un  #largissement  du  spectre  d'emis- 
sion,  au  lieu  de  continuer  3 utiliser  pour  le  DME  de  pr#cision  le  filtrage  fr#quentiel  et  le  codage  en 
espacement  des  impulsions,  il  serait  plus  judicieux  de  profiter  des  techniques  d'etalement  de  spectre  a 
1'emission  et  de  compression  d'impulsion  par  filtrage  adapt#  3 la  r#ception,  utilisees  dans  les  transmissions 
numeriques.  On  obtient  alors  le  syst#me  DME  3 codage  de  phase. (Nous  renvoyons  a l'article  de  S.H.D0DINGT0N, 

A.  LANG,  et  J.  LEGRAND,  r#f#rence  4). 


Description  scmmaire  du  systeme  DME  a codage  de  phase 


Le  systeme  fonctionnant  au  moyen  d ' interrogations-ryponses  utilise  des  impulsions  simples  de  largeur 
3, 5, us  aussi  bien  au  sol  qu'4  bord.  A l'intfirieur  de  chaque  impulsion,  la  porteuse  HF  est  modulee  au  moyen 
d'une  modulation  de  phase  binaire  suivant  un  code  pseudo-aleatoi re  a 31  moments  chacun  ayant  une  dur&e 
d'environ  0,1. us.  La  modulation  numerique  est  du  type  PSK  (Phase  Shift  Keying)  afin  de  simplifier  les  cir- 
cuits de  modulation  et  d'obtenir  la  precision  maximum.  El  1 e pourrait  etre  du  type  MSK  (Minimum  Phase  Shift 
Keying)  si  on  recherchait  avant  tout  une  largeur  de  bande  nlus  faible  et  un  encombrement  du  spectre  moins 
important.  Le  choix  de  31  moments  resulte  de  l'utilisation  d'une  sequence  pseudo-aleatoi  re  de  longueur 
maximum  et  constitue  le  meilleur  compromis  entre  un  gain  de  traitement  suffisant,  une  bonne  precision  et 
une  simplicity  de  realisation  des  circuits  modulateurs-demodulateurs. 


A la  reception,  le  signal, aprSs  changement  de  frequence,  amplification  et  limitation,  est  traite 
dans  un  filtre  adapte  constitue  par  un  correlateur  a ondes  acoustiques  de  surface.  Si  le  code  de  la  modula- 
tion de  phase  est  bien  choisi,  chaque  impulsion  du  signal  utile  fournit  un  pic  d1 autocorrelation  accompagny 
de  lobes  secondaires  de  niveau  faible.  Tout  autre  signal  indesirable  ne  fournit  en  sortie  du  corryiateur 
que  des  residus  d'intercorrelation  qui  ne  sont  pas  pris  en  compte  par  les  circuits  a seui 1 situys  aprys  le 
correlateur.  Ces  signaux  indesirables  peuvent  ytre,  soit  des  impulsions  ayant  le  code  de  phase  attendu,  mais 
dont  la  frequence  HF  est  decalee  (canaux  adjacents),  soit  des  impulsions  a la  frequence  HF  selectionnee, 
mais  n'ayant  pas  le  code  de  phase  desire  (en  particulier  des  impulsions  gaussiennes  DME/TACAN).  Le  pic 
d' autocorrelation  du  signal  utile  presente  une  forme  triangulaire  dont  le  temps  de  montee,  tres  bref,  corres- 
pond a la  duree  d'un  moment  de  la  modulation  de  phase  (0,1, us).  II  faut  noter  que  le  front  avant  du  pic 
d‘ autocorrelation  est  trys  peu  perturbe  par  les  mul ti tra jets  eventuels.  Un  circuit  de  declenchement  4 seuil 
effectue  un  marquage  dans  le  temps  a un  niveau  determine  du  front  avant  du  pic  d' autocorrelation.  Cet  ins- 
tant precis  est  utilise  pour  la  mesure  de  distance. 


Principaux  avantages  du  systeme 


L'utilisation  d'impulsions  simples  codees  en  phase  a remission  et  du  filtrage  adapte  4 la  reception 
procure  au  systeme  tout  son  intyret  : 


- une  grande  precision  dans  la  mesure  des  distances  pouvant  atteindre  40  pieds  (2  o)  ; 


- une  bonne  compatibility  avec  le  systeme  DME/TACAN,  c'est-a-dire  des  perturbations  mutuelles  nygligeables  ; 


- l'obtention  immediate  dans  la  bande  de  frequence  962-1213  MHz,  dyja  occupee  par  le  DME/TACAN,  des  200 
nouveaux  canaux  necessaires  pour  le  DME  de  precision. 


Une  etude,  des  essais  en  laboratoire  et  sur  le  terrain  effectues  en  France  sous  l'egide  du  STNA 
ont  confirme  les  avantages  exprimes  ci-dessus. 


Le  systeme  DME  de  precision  a codage  de  phase  utilisant  les  methodes  modernes  de  traitement  du 
signal  peut  satisfaire  les  besoins  en  mesure  de  distance  pour  1 'atterrissage  pendant  plusieurs  decennies. 
II  est  techniquement  tres  seduisant  et  merite  d'etre  dyveloppy  dans  le  futur. 


EVOLUTION  FUTURE  POUR  LA  NAVIGATION 


Jusqu'a  present,  le  DME  n'est  utilise  pour  la  navigation  qu'associe  au  V0R,  la  mesure  d'angle  ytant 
d'ailleurs  primordiale  pour  le  suivi  d'une  route  aerienne.  Le  DME  est  en  fait  capable  de  jouer  un  role  plus 
important  et  meme  de  devenir  1 ' aide  principale  pour  un  systeme  de  navigation  p-p  utilisant  des  mesures  de 
distance  simultanyes  4 plusieurs  balises. 


etendue. 


Ce  type  de  navigation  peut  maintenant  etre  envisage,  car  la  couverture  EME  s'est  consi dyrablement 


En  France,  comme  le  montrent,  en  annexe,  les  cartes  ytablies  pour  des  altitudes  de  vol  de  8000  pieds 
et  15000  pieds,  la  couverture  est  multiple  sur  la  majeure  partie  du  territoire. 


Sur  T Europe  enti yre,  la  density  des  balises  sera  sensiblement  identique  dans  les  quelques  annees  a 


Aux  Etats-Ums,  sur  94%  de  la  surface  du  territoire,  n'importe  quel  point  est  situe  a une  distance 
infyrieure  4 150  milles  nautiques  d'au  moins  une  dizaine  de  stations. 


Nous  avons  vu  precedemment  que  1 ' information  de  distance  DME  est  d'excellente  quality  et  que  la  pry- 
cision  est  pratiquement  independante  de  la  distance  e*  de  la  position  par  rapport  a la  balise.  Cette  pro- 
priety constitue  un  avantage  fondamental  par  comparaison  aux  systemes  angulaires  dont  la  zone  d' imprecision 
augmente  en  meme  temps  que  l'eloignement. 


Tenant  compte  de  ces  facteurs  et  des  possibilites  actuelles  de  traitement  numyrique  par  calculateur, 
la  Sociyte  Air-France  a dyfini  un  nouveau  concept  de  navigation  base  sur  un  systeme  a multilatyration  par 
DME,  associe  au  systyme  4 inertie  pour  les  avions  qui  en  sont  equipes.  Ce  concept  a fait  l'objet  d'une 
etude  par  MM.  G. COLLIN  et  J.B.  RIGAUDIAS,  citee  en  refyrence  6. 


Ce  type  de  navigation  nycessite  la  connaissance  a bord  des  donnees  relatives  aux  positions  gyogra- 
phiques  des  balises  utilisees.  Toutes  les  erreurs  eventuelles  et  les  inconvenients  entrainys  par  le  stockage 
de  ces  donnees,  leur  introduction  dans  une  memoire  et  surtout  leur  mise  4 jour  pyriodique  peuvent  etre  yvitys 
si  chaque  balise  transmet  direccement  aux  interrogateurs  son  "ytiquette",  c'est-4-dire  1 'ensemble  des  donnyes 
la  concernant.  Ell e devient  alors  ce  que  Ton  appelle  une  balise  "ytiquetye". 


Suivant  ce  concept  de  navigation,  1 'installation  de  bord  type,  pour  Vaviation  commerciale  comprend, 
en  plus  de  l'inertie  eventuelle,  deux  interrogateurs  DME  identiques  fonctionnant  en  etroite  collaboration 
avec  un  calculateur  de  navigation  associe  a un  pilote  automatique.  Chaque  interrogateur  est  capable  de 
l'agilite  de  frequence,  c'est-d-dire  qu'il  peut  travailler  en  partage  de  temps  sur  plusieurs  balises. 

Les  systemes  les  plus  evolu&s  peuvent  meme  etre  dquipes  d'une  selection  automatique  des  stations 
disponibles.  Dans  ce  cas,  l'un  des  interrogateurs  que  Ton  appelle  “lecteur  d'etiquette"  est  commute  sdquen- 
tiellement  en  reception  seulement  sur  chacun  des  canaux  DME  afin  de  fournir  au  calculateur  la  liste  des 
stations  a bonne  portee.  L'autre  interrogateur  effectue  les  mesures  de  distance  par  rapport  aux  balises 
choisies  pat  le  calculateur.  Le  plan  de  vol  est  insere  msnuellement  avant  le  depart  ou  au  cours  du  vol 
s'il  doit  etre  modi  fie. 

Ce  concept  de  navigation  par  mul ti lateration  est  bien  sur  compatible,  pour  1'aviation  generale,  avec 
une  precision  du  meme  ordre  de  grandeur. 

Dans  la  configuration  la  plus  simple,  sans  calculateur  de  navigation,  un  seul  interrogateur  equipe 
d'un  mi croprocesseur  calcule  simultaneme.t  la  distance  a plusieurs  balises  selectionnees  manuellement  et 
fournit  les  coordonnees  geographiques . La  navigation  est  faite  au  moyen  de  cartes  etablies  pour  permettre 
une  bonne  facility  de  lecture.  Partant  de  cet  equipement  minimal,  un  interrogateur  plus  evolue  ayant  un 
calculateur  de  route  simplifie  peut  permettre  de  naviguer  de  balise  en  balise.  Toute  une  gamme  d' equi percents 
de  complexity  croissar.te  peut  ainsi  etre  envisagee  jusqu'a  un  maximum  capable  d'effectuer  une  navigation 
automatique. 

7.  TRANSMISSION  DE  DONNEES  PAR  LE  DME,  BALISES  "ET1QUETEES" 

La  transmission  sol-air  des  donnees  est  effectuee  sous  forme  numerique,  sur  le  canal  de  ’a  balise 
par  emission  d'impulsions  gaussiennes  supplemental  res. 

Les  informations  principales  transmises  sont  : 

- les  coordonnees  geographiques  du  lieu  d' implantation  de  la  balise  : 

. latitude  (comportant  7 caractyres  pour  une  precision  de  la  seconde  d'arc) 
longitude  (comportant  8 caractyres  pour  une  precision  de  la  seconde  d'arc) 

. altitude  (comportant  2 caractyres  pour  une  precision  de  100  pieds) 

- la  declinaison  du  lieu  (2  caractyres  pour  une  precision  de  0,1°)  ; 

- le  canal  DME  sur  lequel  fonctionne  la  balise. 

Pour  transmettre  les  donnees,  deux  methodes  peuvent  convenir  : 

- la  premiere  consiste  a ajouter  une  impulsion  simple  supplemental  re  apres  une  paire  normalement  emise  par 
la  balise  (reponse  ou  remplissage  aleatoire).  Le  triplet  ainsi  forme  constitue  un  bit  de  donnee.  La 
valeur  du  retard  de  1 'impulsion  simple  par  rapport  I la  paire  determine  le  poids  du  bit. 

La  cadence  de  transmission  e,.  par  consequent  la  charge  supplemental  re  de  la  balise  peut  etre  ajustee  a 
la  valeur  desiree,  car  il  n'est  pas  necessaire  de  transmettre  un  bit  pour  chaque  paire  emise  normalement  ; 

- suivant  une  autre  methode,  la  transmission  peut  etre  faite  en  meme  temps  que  1 'emission  des  signes  du 
code  morse  de  l'indicatif.  II  suffit  de  moduler  en  position  chaque  paire  d'impulsions  d'egalisation 

emise  apres  les  pairer  recurrentes  a 1350  Hz.  Ce  dernier  type  de  transmission  presente  1 ' inconvenient  d'etre 
limite  en  capacity  aux  5 informations  indiquees  precedemment  sans  possibility  d'extensions  futures. 

Quel  que  soit  le  type  de  transmission  utilise,  les  donnees  sont  decoupees  en  mots  successifs  comportant 
chacun  un  signal  de  synchronisation,  une  adresse,  le  message  proprement  dit  et  un  ou  plusieurs  bits  de 
parite  permettant  une  detection  d'erreur.  Une  redondance  par  repetition  de  chaque  mot  assure  3 la  trans- 
mission une  grande  security. 

Le  systeme  de  transmission  de  donnees  est  entierement  compatible  avec  le  DME  actuel . Son  adjonction  aux 
balises  opera tionnel les  est  simple,  il  ne  necessite  que  1 'addition  d'un  codeur.  Le  decodage  des  informations 
a bord  ne  sera  effectue  que  par  une  nouvelle  generation  d ' interrogateurs  specialement  adaptes  I la  naviga- 
tion p-p. 

8.  CONCLUSION 

Le  systeme  DME  fonctionnant  en  impulsions  au  moyen  d' interrogations-reponses  a maintenant  30  ans.  Il 
a atteint  sa  maturity,  mais  pas  la  limite  de  ses  possibilites  et  il  est  surement  appeie  a se  developper 
encore  dans  l'avenir. 

Pour  ses  applications  a la  navigation  p-9  pratiquee  actuellement,  son  evolution  sera  limitee  aux 
perfectionnements  technolog iques  des  equipements  qui  amelioreront  peu  a peu  ses  performances. 

Le  developpement  de  la  navigation  p-p  a base  de  mesures  exclusives  de  distances  est  susceptible  de 
lui  apporter  un  nouvel  essor,  autorisant,  grace  a sa  precision,  une  diminution  des  espacements  entre  avions. 

Dans  le  domaine  des  aides  a 1 'atterrissage,  le  DME  jouera  un  role  important,  car  il  sera  associe  a 
I'lLS  et  au  futur  MLS.  Des  progres  considerables  seront  peut  etre  apportes  au  systeme  par  1 'utilisation 
des  techniques  modernes  d'etalement  du  spectre. 
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SUMMARY 

The  Communication,  Navigation,  and  Ident if icat ion  (CNI)  requirements  of  military  aircraft 
have  long  been  satisfied  by  an  implementation  of  the  universally  accepted  black  box  approach. 

This  conventional  solution  to  an  increasingly  complex  problem  has  inherent  limitations  which 
have  given  rise  to  the  development  of  a totally  new  system  architecture.  This  architecture 
is  embodied  in  the  Tactical  Information  Exchange  System  (TIES),  and  it  is  driven  by  the  primary 
goals  of  improving  reliability,  maintainability,  flexibility  and  reducing  size  and  weight. 

The  unique  partitioning  of  the  system  takes  advantage  of  the  latest  advances  in  digital  and 
RF  technology  and  insures  against  premature  obsolescence.  Every  attempt  is  made  to  share 
hardware  resources  by  developing  a family  of  multifunction  programmable  modules,  including 
broadband  RF  components  and  an  all  digital  general  purpose  signal  processor. 

Efforts  to  date  in  the  exploratory  development  program  have  resulted  in  a clear  definition 
of  the  baseline  architecture,  fabrication  of  breadboard  hardware  for  many  of  the  key  elements 
within  the  system,  and  theoretical  analysis  to  evaluate  various  design  alternatives.  On 
going  work  in  each  of  these  areas  continues  towards  the  ultimate  goal  of  total  system  integration 
and  validation  of  the  TIES  concept  for  application  in  the  next  generation  of  Naval  aircraft. 

BACKGROUND 

The  communications,  RF  navigation  and  identification  functions  performed  by  military 
aircraft  remained  rather  simple  up  until  about  the  time  of  the  Vietman  War.  Transfer  of 
command  and  control  information  was  primarily  done  in  the  military  UHF  band  (225-400  MHz) 
through  voice  communication  using  conventional  amplitude  modulation.  Pulsed  type  transmissions 
in  the  Lx  band  (960-1215  MHz)  were  used  for  RF  navigation  and  IFF  (identification,  friend 
or  foe).  The  former  was  performed  through  TACAN  (Tactical  Airborne  Navigation),  a distance 
measuring  equipment  using  fixed  and  mobile  beacons,  while  the  latter  utilized  a discrete 
cod-e  address  system  which  identified  friends  by  their  responding  to  the  proper  code  address 
of  the  day.  Patrol  aircraft,  which  required  information  transfer  beyond-line-of-sight 
communications,  used  the  HF  band  (2-30  MHz)  for  sending  teletype  or  voice  modulated  RF 
signals. 

Advances  in  digital  and  solid  state  technology  have  led  to  enhanced  capabilities  in 
computational  and  sensor  functions,  thus  providing  additional  information  desired  by  higher 
command  authorities.  Every  addition  of  a new  or  improved  function  required  the  addition 
of  a new  functional  equipment.  If  one  projects  into  the  1990  time  frame  there  will  be  an 
expected  wide  use  of  SATCOM  (Satellite  Communications)  spread  spectrum  type  communications 
in  the  VHF,  UHF,  and  Lx  bands,  an  advanced  IFF  system  called  DABS  (Discrete  Address  Beacon 
System),  GPS  (Global  Positioning  System),  and  Collision  Avoidance.  All  of  these  functions 
are  in  addition  to  those  mentioned  previously.  To  support  these  improvements  the  size  and 
cost  of  airborne  platforms  would  continue  to  increase  significantly  using  conventional  design 
approaches. 

Implementation  of  a totally  integrated  CNI  system  for  military  aircraft  would  in  itself 
be  a major  achievement.  The  TIES  concept  goes  much  further  in  that  it  is  structured  around 
a new  system  architecture  which  will  satisfy  the  need  for  improved  reliability,  maintainability, 
flexibility  and  lower  life  cycle  cost.  In  addition,  it  offers  a significant  reduction  in 
size  and  weight  when  compared  to  a conventionally  built  system  with  the  same  set  of  functional 
requirements.  There  is  no  new  waveform  definition  in  TIES.  It  is  instead  an  advanced  concept 
for  processing  the  information  transfer  requirements  that  will  be  imposed  on  the  airborne 
Navy  platform  for  the  1990  time  frame  and  beyond.  Figure  1 gives  an  indication  of  the 
multitude  of  functions  and  the  total  RF  spectrum  which  must  be  considered  for  the  next 
generation  platform,  especially  in  view  of  the  trend  toward  a multimission  type  of  aircraft 
such  as  VSTOL.  Present  day  aircraft  are  each  equipped  with  customized  sensors,  computers 
ai.d  communications  devices  which  address  their  particular  mission.  There  are,  for  example, 
anti-submarine  warfare  (ASW) , attack,  intercept,  reconnaissance  and  electronic  warfare 
(EW)  aircraft,  each  with  a customized  avionics  suite  as  shown  in  Figure  2.  The  multi-mission 
platform  concept  dictates  an  Increased  number  of  CNI  functions  which  a given  aircraft  must 
perform  in  an  attempt  to  satisfy  naval  aviation  requirements  while  keeping  the  cost  down. 

It  implies  that  future  avionics  systems  must  be  capable  of  simple  and  rapid  reconfiguration, 
thus  allowing  any  platform  to  use  a variety  of  sensors  for  other  than  its  primary  missions 
should  the  need  arise.  In  addition,  early  obsolescence  must  also  be  avoided  through  the 
choice  of  a system  architecture  which  is  flexible  enough  to  keep  pace  with  technological 
advancements  by  simple  modular  substitutions. 

SPECIFIC  PROBLEMS  WITH  CONVENTIONAL  CNI  SYSTEM  DESIGN 

A simplified  block  diagram  for  conventional  processing  of  a typical  communication 
function  is  shown  in  Figure  3.  The  only  standardization  attempted  is  to  usually  confine 
the  dimensions  of  each  subsystem  to  a so  called  standard  ATR  size  or  some  fraction  thereof. 
Normally  a ’’system  design  for  a particular  function  consists  of  a series  of  several  Weapon 
Replaceable  Assembles  (WRA's)  or  commonly  called  "black  boxes".  Improvement  in  a platform's 
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operational  capability  has  traditionally  involved  a complete  redesign  of  the  hardware. 

Often  separate  equipments  exist  for  two  or  more  functions  operating  in  the  same  frequency 
band.  TACAN,  IFF,  and  the  proposed  JTIDS  (Joint  Tactical  Information  Distribution  System) 
for  example,  could  share  the  same  synthesizer  and  power  amplifier  design  if  designed  properly. 

The  same  holds  true  in  the  UHF  band  where  there  are  a multitude  of  transceivers,  (ARC-159, 
j ARC-143,  ARC-156,  etc.)(  aii  sharing  the  same  part  of  the  RF  spectrum  to  perform  slightly 

different  functions.  As  a result,  acquisition  costs  are  inflated  because  of  the  nonrecurring 
engineering  which  is  duplicated  for  each  new  function.  Life  cycle  costs  are  inflated  because 
, of  the  need  for  specialized  test  and  support  equipment  for  each  subsystem,  e.g.,  TACAN 

simulator,  IFF  simulator,  Link  11  simulator.  Link  4 simulator,  etc.  There  are  also  unique 
training  requirements  associated  with  each  subsystem  and  a proliferation  of  non-standard 
modules  which  must  be  stocked,  thus  causing  a logistics  support  problem  and  impairing  maintenance 
capabilities. 

The  conventional  design  imposes  a size  and  weight  burden  on  the  platform  because  of 
the  need  to  carry  hardware  which  is  required  for  only  parts  of  the  mission.  An  ocean  sur- 
veillance platform,  for  example,  may  have  a projected  requirement  for  up  to  forty  different 
information  transfer  functions.  An  analysis  of  the  instantaneous  number  of  operations  needed 
during  a mission  may  show  that  only  six  functions  are  required  simultaneously.  There  is 
no  way  to  take  advantage  of  this  low  percentage  of  mission  utilization  time  for  some  functions 
with  the  dedicated  black  box  approach.  Another  difficulty  with  the  standard  avionics  design 
is  the  inability  to  upgrade  system  capability  with  technological  advances.  If  for  example, 
a significant  improvement  in  the  efficiency  of  a high  power  Lx  band  amplifier  were  achieved, 
it  could  not  be  readily  incorporated  into  any  existing  hardware  without  costly  redesign. 

Quite  often  this  causes  premature  obsolescence  to  occur  during  the  procurement  cycle  of 
a particular  system. 


The  last  criticism  of  the  present  aircraft  CNI  design  to  be  discussed  here  is  the 
abrupt  loss  of  function  which  can  occur  through  hardware  failure.  With  the  conventional 
approach,  if  a critical  function  such  as  IFF  is  lost,  the  mission  must  be  aborted  even 
though  the  aircraft  may  otherwise  be  capable  of  performing  its  mission.  The  only  way  to 
achieve  modes  of  failure  other  than  complete  loss  of  function  is  to  carry  fully  redundant 
equipments.  The  alternative  is  a totally  integrated  CNI  design  which  allows  for  an  overall 
system  failure  mode  of  "graceful  degradation",  i.e.,  reassignment  of  hardware  resources 
on  a priority  basis  through  fault  isolation. 

TIES  SYSTEM  ENGINEERING 

The  key  element  of  success  for  the  TIES  program  is  the  definition  of  a new  system 
architecture  which  tackles  straight  on  the  problems  resulting  from  the  conventional  CNI 
design.  This  architecture  is  shown  symbolically  in  Figure  4.  It  provides  significant  advantages 
over  the  conventional  approach  by: 

(1)  Utilizing  a family  of  multipurpose,  programmable  modules  which  can  be  used  for 
processing  all  CNI  requirements  and  eliminate  costly  redesign. 

(2)  Reducing  logistics  requirements  by  eliminating  the  need  to  stock  a large  variety 
of  non-standard  parts. 

(3)  Improving  maintainability  by  incorporating  a well  designed  Built-In  and  External 
Test  philosophy,  simplifying  training  requirements,  and  eliminating  a wide  variety  of  test 
and  support  equipment. 

(4)  Eliminating  the  threat  of  early  obsolescence  and  allowing  for  functional  expansion 

or  contraction  through  the  use  of  modular  resources  and  the  interconnecting  signal  distribution 
subsystem. 

(5)  Not  allowing  a single  module  failure  to  cause  abrupt  loss  of  function,  i.e., 
graceful  degradation  is  inherent  in  the  design. 

A description  of  the  system  architecture  must  begin  with  a definition  of  the  three  basic 
subsystems  in  TIES  as  shown  in  Figure  5.  They  are: 

(1)  The  Frequency  Conversion  Subsystem 

(2)  The  Signal  Distribution  Subsystem 

(3)  The  Signal  Conversion  Subsystem 

The  design  of  each  subsystem  is  driven  by  a desire  to  realize  all  of  the  advantages 
listed  above. 

The  Frequency  Conversion  Subsystem  consists  of  the  antenna  subsystem  and  the  front 
end  RF/IF  hardware  used  for  transmission  and  reception.  The  Signal  Distribution  Subsystem 
consists  of  a wideband  FDM  (Frequency  Division  Multiplex)  bus  and  a digital  control  bus. 

The  FDM  bus,  which  is  a key  element  within  the  TIES  architecture,  provides  the  link  between 
the  Frequency  Conversion  Subsystem  and  the  Signal  Processing  resources  of  the  system.  The 
digital  control  bus  interconnects  the  programmable  modular  resources  to  a master  or  executive 
controller.  Finally,  the  Signal  Conversion  Subsystem  is  the  name  given  to  the  digital  signal 
processing  hardware  at  the  source/sink  end  of  the  system.  The  signal  flow  for  a typical 
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received  signal  is  shown  in  Figure  4.  Depending  upon  its  RF  band  (UHF  in  the  example  shown), 
it  enters  through  part  of  the  antenna  subsystem  into  an  RF  front  end  amplifier/receiver 
located  in  very  close  proximity  to  the  antenna.  It  goes  through  the  first  stages  of  filtering 
and  amplification  and  is  then  down  converted  to  a standard  70  MHz  IF  frequency. 

It  is  then  launched  onto  the  FDM  bus  cable  through  an  on-bus  coupler  unit.  This  device 
also  amplifies,  filters  the  signal  and  upconverts  it  into  an  appropriate  frequency  slot 
for  distribution  on  the  wideband  FDM  cable.  The  signal  is  then  extracted  from  the  FDM 
cable  on  the  signal  processing  end  of  the  system  by  an  off-bus  coupler  unit  which  basically 
performs  the  inverse  operation  of  the  on-bus  coupler,  i.e.,  downconversion  back  to  the 
standard  70  MHz  IF,  filtering  and  amplification.  It  then  enters  one  of  the  signal  conversion 
units,  where  the  waveform  is  converted  back  to  a baseband  signal  and  distributed  to  the 
appropriate  user  interface  through  a data  processor.  The  data  processor  performs  tasks 
such  as  error  correction  and  encoding,  data  formatting  for  display  or  I/O  (input /out put) 
buffering  to  the  related  sink.  In  the  transmit  mode,  the  signal  flow  is  reversed  and  the 
signal  processing  elements  become  signal  generators.  A detailed  description  of  each  of 
the  three  basic  subsystems  of  TIES  follows. 

Frequency  Conversion  Subsystem 

The  current  baseline  for  the  TIES  Frequency  Conversion  Subsystem  consists  of  four  bands 
of  RF  coverage,  Lx  Band  (960-1215  MHz),  UHF  band  (225-400  MHz),  VHF  band  (30-225  MHz)  and 
HF  band  (2-30  MHz) . Within  each  of  these  bands  there  are  multiple  receiver  requirements 
which  are  satisfied  by  cascading  programmable  analog  modules  such  as  synthesizers,  IF  amplifiers, 
and  filters.  Any  in  band  waveform  can  be  processed  through  any  one  of  these  multiple  receive 
channels.  Every  attempt  is  made  to  use  the  same  modular  components  across  the  four  frequency 
bands  as  well  as  within  each  band.  The  programmable  IF  amplifier  shown  in  Figure  4 is  an 
example  of  such  standardization.  All  of  the  received  signals  are  downconverted  to  a 70  MHz 
IF  center  frequency  before  they  are  coupled  to  the  FDM  signal  distribution  bus.  In  the 
transmit  mode  a particular  set  of  RF/IF  resources  are  utilized  in  each  band  to  provide  RF 
drive,  selectivity,  high  level  modulation,  and  RF  power  amplification.  The  input  to  the 
transmitter  chain  is  a standard  70  MHz  signal  from  the  FDM  signal  distribution  bus.  The 
programmable  hardware  of  the  frequency  conversion  subsystem  is  controlled  by  the  remote 
microprocessors  shown  in  Figure  4.  Front  end  channel  tuning,  IF  bandwidth,  and  gain  are 
some  of  the  parameters  which  are  under  microprocessor  control.  Other  features  of  the  Frequency 
Conversion  Subsystem  afforded  by  the  modularity  and  programmability  of  the  hardware  resources 
are  a powerful  built-in-test  scheme  and  a fail-soft  mode  in  the  event  of  front  end  failure. 

In  a typical  case,  a failure  in  the  first  RF  amplifier  would  be  detected  using  the  remote 
pilot  generator  and  fault  isolation  software.  Signal  bypass  hardware  could  then  be  activated 
to  circumvent  the  problem,  although  with  reduced  performance  such  as  degraded  receiver 
sensitivity.  In  this  case,  there  would  still  be  enough  sensitivity  to  allow,  for  example, 
emergency  navigation  capability. 

The  remaining  major  element  of  the  Frequency  Conversion  Subsystem  to  be  discussed 
is  the  Antenna  System.  No  detailed  antenna  design  has  yet  been  formulated,  however,  the 
considerable  de/elopment  underway  in  directed  and  adoptive  array  techniques  is  being  closely 
monitored.  Algorithms  for  adoption  of  arrays  can  be  incorporated  within  the  TIES  architecture 
to  provide  phase  and  amplitude  adjustments  to  the  antenna  elements.  Parameters  not  normally 
available  to  adaptive  arrays,  such  as  channel  measurement  and  error  rate  measurements,  can 
also  be  incorporated  with  the  antenna  algorithms  to  provide  better  performance.  Arrays 
also  have  the  advantage  in  that  they  can  be  programmed  for  the  mode  of  operation  desired. 
Omnidirectional,  sector  scan,  directed  beam,  or  adaptive  antennas  can  all  be  implemented 
with  a set  number  of  antenna  elements.  The  ultimate  antenna  design  for  TIES  will  be  directed 
towards  providing  a multiband  system  which  is  flexible  enough  to  meet  all  of  the  CNI  waveform 
requirements. 

Signal  Distribution  Subsystem 

The  Signal  Distribution  Subsystem  is  composed  of  a wideband  FDM  bus  and  a digital 
control  bus.  The  FDM  bus  is  fundamental  to  the  TIES  architecture.  It  provides  the  basis 
for  the  flexibility,  modularity,  and  distributed  nature  of  TIES.  Through  the  FDM  bus  any 
set  of  RF/IF  resources  in  the  Frequency  Conversion  Subsystem  can  be  connected  to  any  set 
signal  processing  resources  in  the  Signal  Conversion  Subsystem.  The  concept  of  graceful 
degradation  is  dependent  on  this  feature.  The  FDM  bus  also  allows  the  RF/IF  package  to 
be  placed  in  very  close  proximity  to  the  antenna  which  even  by  a very  conservative  estimate 
can  eliminate  3 to  5 db  of  transmission  line  loss  between  the  receiver/transmitter  and 
antenna  port.  This  3 to  5 db  translates  directly  into  size,  weight  and  prime  power  savings. 
Flexibility  is  achieved  through  the  FDM  bus  approach  since  sets  of  modular  hardware  for 
both  the  Frequency  Conversion  and  the  Signal  Conversion  Subsystems  can  be  added  or  removed 
from  the  system  with  relative  simplicity.  The  bus  is  analogous  to  a practical,  low  cost 
CATV  distribution  system.  It  consists  of  a series  of  on/off  bus  coupling  units  and  separate 
transmit  and  receive  signal  cables.  The  coupling  units  are  synthesizer/filter  combinations 
which  allow  standard  70  MHz  IF  signals  to  be  upconverted  to  the  bus  channel  assignment 
for  the  transmit  bus  or  which  downconvert  the  bus  assigned  channel  to  70  MHz  coming  off 
of  the  receive  bus.  Dual  cables  may  be  routed  for  standby  redundancy.  Loop  back  testing 
may  also  be  achieved  by  connecting  the  transmit  bus  to  the  receive  bus.  The  bus  cable 
itself  is  practically  unsaturating,  being  extremely  broadband  in  nature  (30  KHz  to  1500  MHz). 
Channel  assignments  are  presently  being  maintained  in  the  300  to  500  MHz  portion  of  the 
band,  each  channel  being  10  MHz  wide.  Line  drivers  can  be  added  at  strategic  points  along 
the  bus  to  provide  cable  runs  more  than  adequate  to  cover  the  entire  airframe  while  maintaining 
the  specified  noise  figure  of  the  system. 
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The  digital  control  bus  is  conveniently  broken  into  two  requirements.  In  one  case 
digital  data  rates  on  the  order  of  10  Megabits  must  be  transferred  for  receiver  control 
parameters  in  processing  spread  spectrum  type  signals.  There  is  also  a need  for  a lover 
rate  control  bus  on  the  order  of  1 Megabit  for  all  of  tl  status  and  routine  control  require- 
ments such  as  system  initialization,  FDM  bus  channel  assignments  and  built-in-test.  Ideally, 
separate  channel  assignments  could  be  reserved  on  the  wideband  FDM  bus  for  handling  both 
the  8 low  and  fast  digital  control  bus  requirements. 

Signal  Conversion  Subsystem 

In  the  TIES  context,  there  are  two  signal  processors  as  shown  in  Figure  4.  A distinction 
is  made  relative  to  the  bandwidth  requirements  in  each  unit.  Narrowband  refers  to  signals 
less  than  about  300  KHz,  wideband  greater  than  300  KHz.  Under  this  definition  the  current 
TIES  baseline  calls  for  AM,  FM  SSB,  Link  4,  Link  11  and  TTY  waveforms  to  be  handled  in  the 
NBSCU  (Narrowband  Signal  Conversion  Unit)  and  JTIDS,  TACAN  and  IFF  to  be  processed  in  the 
WBSCU  (Wideband  Signal  Conversion  Unit). 

Each  signal  processor  is  under  control  of  a remote  microprocessor  which  receives  instructions 
from  the  executive  computer.  The  control  system  configures  the  processor  as  a modulator 
or  demodulator  for  a particular  waveform.  Both  signal  conversion  units  interface  to  the 
receive  and  transmit  FDM  cables  at  a common  70  MHz  IF  frequency.  The  WBSCU  must  also  interface 
directly  to  the  Lx  band  frequency  conversion  subsystem  to  provide  channelization  assignments 
to  the  fast  hopping  synthesizers  and  direct  AGC  (Automatic  Gain  Control)  to  the  IF  amplifiers 
for  certain  types  of  waveforms.  The  baseband  information  is  interfaced  to  the  NBSCU  and 
WBSCU  through  the  device  labled  data  processor  in  Figure  4.  The  data  processors  are  used 
for  bit  formatting,  error  detection  and  correction,  coding/decoding,  and  I/O  interface 
functions. 

The  design  philosophy  in  the  TIES  signal  processing  area  is  to  pay  the  burden  in  cost 
and  size  for  a set  of  programmable  resources  which  can  be  time  shared  to  process  a variety 
of  real  time  waveforms.  Digital  correlators,  SAW  (Surface  Acoustic  Wave)  devices  and  CCD’s 
(Charge  Coupled  Devices)  are  examples  of  the  kinds  of  technology  being  employed  in  designing 
the  signal  conversion  units.  An  implementation  using  a general  purpose  high  speed  digital 
processor  has  also  been  demonstrated  for  the  Narrowband  Signal  Conversion  Units. 

HOW  THE  TIES  ARCHITECTURE  PROVIDES  SPECIFIC  ADVANTAGES 


External  and  Built  In  Test  (BIT) 

In  developing  a system  test  philosophy  for  TIES,  a distinction  is  made  between  external 
and  built-in-test.  External  test  is  primarily  an  on  the  deck  check  out  which  requires  the 
utilization  of  peripheral  support  equipment  and  typically  gives  more  detailed  information 
on  system  status.  It  might,  for  example,  isolate  a problem  in  the  Lx  band  receive  section 
to  a faulty  IF  amplifier  module  which  could  then  be  replaced.  Built  in  test  gives  an  on- 
line operational  readiness  assessment  of  the  system  (GO/NO  GO  condition)  and  is  completely 
self-contained.  The  criteria  for  passing  BIT  is  predetermined  and  set  at  some  minimum 
threshold  level  at  strategic  points  throughout  the  system. 

The  TIES  architecture  allows  an  extremely  powerful  external  test  concept  whereby  every 
IF  signal  within  the  system  can  be  accessed  at  one  coax  cable  port  on  the  FDM  bus.  The 
decoupling  hardware  used  at  the  test  port  is  exactly  the  same  as  that  used  within  the  system 
(OFF  bus  couplers).  Standard  test  equipment  can  be  used  to  receive  signals  on  the  receiver 
FDM  cable,  and  to  inject  signals  on  the  transmit  FDM  cable.  Signals  can  be  preprogrammed 
to  execute  standard  test  routines.  The  alternative  is  to  produce  a variety  of  unique  support 
equipments  for  each  set  of  CNI  avionics  on  board  the  aircraft. 

The  Built-In-Test  philosophy  for  TIES  is  dependent  on  a certain  amount  of  overhead 
being  paid  for  in  test  circuitry.  This  overhead  takes  the  form  of: 

(1)  Pilot  generators  to  provide  test  signals. 

(2)  Status  information  being  stored  in  remote  microprocessors. 

(3)  Initialization  and  control  routines  in  the  executive  computer. 

(4)  Fault  detectors  with  appropriate  interfacing  hardware  to  the  remote  microprocessors. 

BIT  features  are  used  primarily  in-flight  to  provide  on-line  status  and  to  achieve  many 
useful  fail-soft  modes  of  operation. 

In  a typical  scenario,  the  executive  computer  would  periodically  generate  a command 
to  initiate  a test  message  throughout  the  transmit  and  receive  paths.  The  message  is  completely 
wrapped  around  and  received, then  it  is  compared  to  what  was  sent.  Acceptable  signal  levels 
are  also  present  throughout  the  RF/IF  signal  path  and  monitored  using  peak  detecting  circuits. 
These  peak  detectors  are  used  in  conjunction  with  low  cost  Analog  to  Digital  Convertors 
to  send  and  store  signal  parameters  in  the  remote  microprocessors.  The  status  information 
is  always  available  to  the  operator  through  the  executive  controller  to  determine  if  the 
system  is  functioning  according  to  some  predetermined  minimum  performance  criteria.  Alerts 
can  automatically  be  given  to  the  operator  and  work  around  modes  of  operation  can  automatically 
be  Implemented  to  provide  graceful  degradation. 
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The  FDM  bus  also  provides  a unique  BIT  feature  Inherent  in  the  TIES  architecture. 

Full  connectivity  can  be  established  between  any  set  of  signal  processing  resources  and 
RF  resources.  Thus,  for  example,  on  narrowband  signal  conversion  unit  can  be  set  up  as 
a modulator  for  some  signal  and  set  up  on  a specific  channel  assignment  to  talk  to  the 
other  narrowband  signal  conversion  unit  which  is  set  up  as  a demodulator.  The  roles  of 
the  two  units  can  then  be  interchanged.  This  full  loop  back  processing  can  be  established 
among  all  IF  signals  in  the  system. 


Reduced  Logistics  and  Training  Requirements 


In  the  TIES  architecture  maximum  effort  is  being  put  forth  to  develop  a set  of  multi- 
function/multipurpose modules  which  can  be  shared  for  processing  different  waveforms  in 
the  same  frequency  band  and  in  many  cases  across  multiple  frequency  bands.  As  an  example, 
the  programmable  70  MHz  IF  amplifier  which  has  been  developed  is  used  for  the  HF,  VHF,  UHF 
and  Lx  bands.  The  broadband  VHF/UHF  power  amplifier  has  an  extended  frequency  range  from 
30  to  400  MHz.  Other  examples  can  be  found  throughout  the  system.  The  net  result  is  to 
greatly  reduce  the  number  of  different  spares  which  must  be  stocked  and  inventoried.  Obviously, 
the  non-recurring  engineering  cost  is  higher  in  developing  a multipurpose  programmable  IF 
amplifier  at  70  MHz  than  a designated  piece  of  hardware  but  we  feel  that  the  long  term 
payoff  warrants  this  initial  investment. 


Training  is  simplified  through  the  TIES  architecture  since  the  system  consists  of  sets 
of  standard  modular  resources  all  under  control  of  a single  system  controller  using  one 
programming  language  and  a standard  I/O  interface.  In  the  conventional  approach,  each 
CNI  function  has  unique  control  requirements,  I/O  interface,  test  routines  and  functional 
descriptions  which  must  be  learned.  In  addition,  there  is  the  added  burden  of  operating 
the  peculiar  support  equipment  associated  with  each  subsystem.  The  testing  philosophy 
for  TIES  as  previously  discussed  in  the  section  on  Built-In  and  External  Test,  establishes 
a common  test  routine  for  the  entire  CNI  system. 


Size  and  Weight  Savings 


The  TIES  architecture  offers  a significant  size  and  weight  saving  over  the  conventional 
approach  primarily  for  two  reasons.  First,  because  the  FDM  bus  concept  allows  one  to  place 
RF  hardware  physically  close  to  the  antenna.  As  mentioned  earlier,  this  results  in  a 3 
to  5 db  savings  in  cable  loss,  which  translates  directly  into  reducing  prime  power  and  reducing 
size  and  weight.  Some  basic  calculations  illustrating  these  savings  are  shown  in  Figure  6. 

It  is  interesting  to  note  that  in  the  TIES  system  there  is  a penalty  paid  for  additional 
hardware  such  as  the  remote  microprocessor  and  built-in-test  circuitry  which  are  part  of 
the  frequency  conversion  subsystem  package.  The  price  paid  is  reduced  efficiency,  nevertheless, 
the  TIES  architecture  still  offers  a clear  cut  advantage  in  prime  power  savings. 


The  other  architectural  advantage  which  reduces  size  and  weight  is  the  elimination  of 
redundant  hardware  through  time  sharing  of  the  modular  resources.  A sizing  of  the  platform 
operational  requirements  is  done  to  determine  simultaneous  processing  needs.  In  the  Lx 
band,  for  example,  if  one  realizes  that  a function  like  TACAN  is  needed  only  on  operator 
demand  and  that  an  acceptable  countdown  level  can  be  tolerated  for  IFF  then  the  concept 
of  using  a common  power  amplifier  and  a common  wideband  signal  processor  for  all  the  Lx 
band  signals  becomes  very  attractive.  Separate  control  boxes  are  also  eliminated  by  using 
a digital  control  bus  which  is  managed  by  the  platforms  executive  computer. 


Flexibility  and  Growth  Potential 


One  of  the  predominant  problems  in  conventional  system  design  is  to  achieve  interoperability 
on  a level  appropriate  to  a particular  platform  need.  Retrofit  is  out  of  the  question 
for  the  TIES  concept,  however,  the  system  design  is  flexible  enough  to  allow  a 1955  aircraft 
to  talk  to  a projected  2005  aircraft.  The  carrier  based  ASW  aircraft  may  require  HF  voice, 

HF  data,  UHF  voice,  TACAN,  IFF  and  JTIDS.  The  command  and  control  aircraft  may  require  those 
functions  plus  VHF  data  and  multiple  HF,  VHF,  and  Lx  band  channels.  Both  aircraft  can  be 
accommodated  within  the  TIES  architecture  using  the  FDM  bus  design  and  the  number  of  standard 
modular  elements  peculiar  to  the  need.  The  software  control,  BIT  and  external  test  is  modular 
in  both  cases  and  is  merely  loaded  with  the  proper  input  variables  to  handle  either  need. 

The  narrowband  and  wideband  signal  conversion  units  are  functionally  programmable  and  can 
serve  both  requirements.  Early  obsolescence  is  eliminated  since  the  addition  of  new  functions 
or  the  need  for  enchanced  capability  can  be  addressed  on  a modular  basis  rather  than  a total 
system  redesign. 


PROGRAM  STATUS  AND  ACCOMPLISHMENTS 

The  TIES  program  is  being  sponsored  by  the  Naval  Air  Systems  Command  (AIR-360)  with 
the  Naval  Air  Development  Center  acting  as  the  lead  laboratory.  Efforts  are  on-going  in 
the  exploratory  development  phase  with  the  transition  to  advanced  development  (ADM  phase) 
scheduled  to  begin  in  1979.  A baseline  TIES  system,  similar  to  that  shown  in  Figure  4, 
is  being  integrated  into  the  TIES  laboratory  at  NAVAIRDEVCEN . This  lab  integration  will  culminate 
in  a full-up  TIES  feasibility  demonstration  in  early  1980. 

The  system  currently  being  developed  and  tested  is  based  on  a series  of  earlier  study 
contracts  which  defined  the  system  architecture  and  signal  processing  requirements.  Basic 
design  concepts  have  also  been  studied  and  documented  in  the  digital  multiplex  area,  the 
frequency  division  multiplex  area,  the  RF,  and  control  subsystem  areas.  Some  of  the  major 
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modular  developments  which  have  been  completed  and  provide  a firm  foundation  for  the  system 
architecture  and  design  goals  will  be  discussed.  Ultimately,  it  is  this  technology  base 
that  Is  the  key  as  to  whether  or  not  TIES  will  be  a viable  system  concept  for  our  next 
generation  military  aircraft. 

1 Kilowatt  Lx  Band  Solid  State  Amplifier 

A solid  state  1 Kw  power  amplifier  has  been  constructed  and  tested  using  a 250  watt 
10X  duty  cycle  transistor  as  the  basic  building  block.  The  amplifier  is  broadband  (960- 
1215  MHz),  requires  no  tuning,  and  will  satisfy  the  requirements  for  JTIDS,  TACAN,  or  IFF 
signals.  The  drive  level  required  is  50  watts.  Its  size  is  approximately  9.5  x 4.5  x 1 inch. 
The  transistor  contractor  is  Power  Hybrids  Incorporated. 

Fast  Hopping  Lx  Band  Synthesizer 

This  fast  hopping  indirect  frequency  synthesizer  provides  the  LO  injection  for  receivers 
used  for  JTIDS  and  TACAN.  It  operates  from  1025-1150  MHz,  switches  in  1 MHz  steps  and  settles 
anywhere  wlthio  the  band  in  13  microseconds  to  6 KHz  of  the  selected  frequency.  The  power 
output  is  +17  dBm  and  the  input*  power  required  is  10  watts.  The  size  of  the  brassband 
model  is  10  x 10  x 10  centimeters.  The  contractor  is  ZETA  Laboratories. 

Lx  Band  Receiver  Front  End 

The  front  end  receiver  is  used  to  receive  JTIDS,  TACAN,  and  IFF  signals  and  covers 
the  Lx  Band  from  960  to  1215  MHz.  The  fast  hopping  frequency  synthesizer  is  used  as  the 
local  oscillator.  High  and  low  side  injection  is  used  to  convert  the  Lx  band  down  to  a 
standard  70  MHz  IF  frequency.  The  receiver  uses  two  and  five  pole  varactor  tuned  filters 
which  are  controlled  by  an  8 bit  control  word.  The  3 dB  bandwidth  of  the  filters  is  approxi- 
mately 18  MHz.  Size  is  approximately  10  x 10  x 2 centimeters.  The  contractor  is  ZETA 
Laboratories. 

Programmable  IF  Amplifier 

This  amplifier  module  is  designed  to  provide  the  proper  gain,  filtering  and  transfer 
characteristic  for  the  signal  being  received  via  programmable  control.  The  module  which 
has  been  built  has  a 70  MHz  center  frequency  and  is  capable  of  log,  linear,  or  limiting 
performance  with  either  fast  or  slow  AGC.  The  gain  of  a single  module  is  25  dB.  The  brass- 

board  size  is  approximately  12  x 4 x 3 centimeters.  The  contractor  is  ZETA  Laboratories. 

Programmable  IF  Filter 

The  IF  filter  module  is  a programmable  surface  wave  device  which  also  has  a 70  MHz 
center  frequency.  It  can  be  programmed  to  any  one  of  four  bandwidths;  30  KHz,  70  KHz, 

350  KHz  or  7 MHz  at  the  3 dB  points  with  a 3/1  shape  factor.  Its  size  is  approximately 

2 x 3 x 0.5  inches.  The  contractor  is  Teledyne  Incorporated. 

Broadband  RF  Power  Amplifier  (2-400  MHz) 

The  objective  of  this  development  program  was  to  develop  a 30  dB  gain  single  broadband 
amplifier  chain  with  an  AM  carrier  output  power  capability  of  12.5  watts  from  118  to  400  MHz, 
an  FM  carrier  output  of  15  watts  minimum  from  30  MHz  to  400  MHz  and  linear  operation  for 
single  sideband  operation  in  the  2 to  30  MHz  frequency  range.  A high  level  modulation 
capability  for  the  amplifier  chain  is  also  provided  in  each  mode  of  operation.  The  efficiency 
of  the  amplifier  is  50Z  minimum  from  30  to  400  MHz.  A brassband  model  of  the  amplifier 
consisting  of  a pre-driver,  driver,  and  power  amplifier  has  been  fabricated  and  delivered 
to  NAVAIRDEVCEN  and  is  meeting  these  design  goals.  A miniturization  program  will  follow. 

The  contractor  is  Power  Hybrids  Incorporated. 


On-Off  Bus  Coupler 

The  On-Off  Bus  Coupler  is  part  of  the  standard  Interface  which  is  capable  of  converting 
the  70  MHz  IF  frequency  to  any  frequency  from  300  MHz  to  500  MHz.  The  coupler  i6  operable 
from  50  KHz  to  1 GHz  with  0.5  dB  insertion  loss.  The  excess  bandwidth  can  be  used  for  adding 
additional  signals  not  Included  in  the  basic  CNI  requirements  such  as  audio  or  video  distribution. 
The  size  of  the  coupler  is  approximately  1 x 1 x 0.7  Inches  exclusive  of  the  synthesizer 
used  for  the  frequency  conversion.  The  contractor  is  Mini  Circuits  Laboratory. 

Narrowband  Signal  Conversion  Unit 


A TIES  brassboard  Narrowband  Signal  Conversion  Unit  has  been  completed  and  is  currently 
being  tested  and  integrated.  The  processor  uses  2900  series  microprocessor  components  for 
implementation  of  recursive  digital  filters  in  a multiplexed  sampling  scheme  to  provide 
simultaneous  processing  of  three  channels  in  any  combination, transmit  or  receive, for  AM, 

FM,  single  sideband  and  FSK  modulated  signals.  The  unit  can  also  be  programmed  to  provide 
a single  wideband  processing  capability  (48  KHz) . An  8080  microprocessor  provides  man 
machine  interface  (via  R5-232  channel)  for  initialization,  mode  selection,  and  loading 
of  parameters  for  the  digital  processing  section.  The  contractor  for  the  NBSCU  is  General 
Dynamics  Corporation,  San  Diego,  California. 
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